The emergence of large language models (LLMs) has significantly advanced natural language processing (NLP); however, their capacity to generate human‐like content introduces serious security concerns. In particular, the misuse of LLMs for disinformation and impersonation on social media platforms such as X creates new opportunities for large‐scale manipulation and deception of users. This study aims to conduct a comprehensive investigation to (i) understand the distinct stylistic features effectively mimicked by 10 different LLMs and (ii) distinguish between LLM‐driven and human authors when LLMs are explicitly instructed to mimic a specific human writing style. In particular, we design adversarial prompts to mimic the writing style of human authors based on key stylometric features (quantitative analysis of writing style) and assess the mimicking effectiveness of different LLMs through extensive statistical testing. In addition, we conduct a survey that gauges human ability to recognize the author of a text and train machine learning models to identify human‐ and LLM‐driven authors, focusing on scenarios where specifically crafted adversarial prompts are employed to facilitate style impersonation. Our findings demonstrate that, when explicitly instructed, LLMs can effectively replicate features of human writing style. In addition, the survey results indicate that it is challenging for the participants to distinguish between the different types of authors. In fact, the participants only demonstrated a classification accuracy of 15% in correctly identifying the text generated by the LLM. In contrast, high detection performance is achieved only when the training data incorporate adversarially generated LLM samples produced using impersonation‐oriented prompts. Under this threat‐model–aligned training regime, stylometric‐based classifiers exhibit strong discriminative capability, attaining classification accuracy of up to 99% in distinguishing human‐authored text from LLM‐generated authorship.

Although the study of software transparency has deep roots in software engineering, a shared definition and practical application in real-world development contexts remain elusive. Through an in-depth analysis of the academic and industrial landscape, this article provides an overview of the current state of knowledge on software transparency, outlining a path to a deeper understanding of the subject for both developers and researchers. The challenge of software transparency involves not only establishing a formal, widely accepted understanding within the community, but also measuring and quantifying it in production environments. To this end, we survey academics and developers to evaluate an innovative approach to defining transparency and present a vision of a new framework for its quantification.

In recent years, ransomware attacks have attracted the attention of researchers and companies, prompting new issues in identifying effective defense techniques. The study provides a comprehensive analysis of ransomware attacks and their employed tactics from 2020 to 2024, leveraging a large dataset of over 16,000 documented ransomware incidents involving 155 distinct gangs. Using this data, we identify the exploited software vulnerabilities (CVEs) and map them to specific adversarial behaviors within the MITRE ATT&CK framework. In addition to this technical mapping, we differentiated between broadly targeting “generalist” gangs and industry-focused ”specialist” gangs, and we examined variations in attack patterns across target sectors and geographic origins. Our methodology reveals the core ”ransomware blueprint”: a unified kill-chain model comprising recurring techniques spanning initial access through encryption. Key findings include the use of high-severity, widely deployed CVEs (particularly public-facing exploits, such as T1190) as entry points, followed by routine privilege escalation, lateral movement, and impact actions (e.g., T1486 for data encryption). The analysis also reveals regional and sectoral differences: (i) Russian-origin groups often emphasize rapid disruption and recovery inhibition, and (ii) other groups focus on stealthier reconnaissance. Generalist gangs (e.g., LockBit, Cl0p, ALPHV) employ advanced techniques across multiple industries, while specialist gangs concentrate on narrower sectors, using simpler methods such as phishing and credential reuse. Moreover, the number of shared techniques is employed to assess the degree of interconnection among the gangs. These findings provide actionable intelligence for defenders, highlighting the need for multi-layered defenses, targeted vulnerability management, and sector-specific hardening strategies to mitigate evolving ransomware threats.

A Software Bill of Materials (SBOM) is an inventory of the software components used to build a product, which can help customers track security risks throughout the development lifecycle. The popularity of SBOMs grew in May 2021 when the White House issued an executive order to improve the security of the software supply chain and the transparency of the government’s software inventory. Although the growing interest in SBOM, many open challenges need to be addressed to help reduce exposure to cyber risks and enhance the security of software supply chains. To help the industry and research assemble the roadmap to achieve SBOM adoption in practice, in this paper, we analyze the challenges related to enabling technologies and the open issues that research must investigate. Furthermore, we perform a comparative analysis of the existing tools to generate SBOMs, demonstrating that the enabling technologies have not yet reached full automation and maturity.

The rapid spread of unknown malware has prompted many companies and researchers to improve their detection and classification systems. Cyber security companies must deal with the newest malware samples captured by their honeypots, aiming to analyze and classify them to develop several countermeasures. This process could only be feasible with a strong ground truth baseline; companies could only securely store the samples, waiting for further developments. This paper proposes a multi-step approach to support the classification process of unknown malware samples. Specifically, our approach first leverages well-known classification techniques and third-party services to collect as much information as possible about the samples and combines them with Machine Learning (ML)-based techniques to classify the remaining samples. Our case study, conducted on industrial data, shows how the combination offers superior performance than using each method individually.

Machine learning (ML) is essential in modern technology, driving complex data-driven decisions. By 2025, daily data generation will exceed 463 exabytes, increasing ML’s influence and ethical risks of data exploitation and discrimination. The European Union’s Artificial Intelligence Act highlights the need for ethical AI solutions.

Abstract Blockchain is a cross‐cutting technology allowing interactions among untrusted entities in a distributed manner without the need for involving a trusted third party. Smart contracts (i.e., programs running on the blockchain) enabled organizations to envision and implement solutions to real‐world problems in less cost and time. Given the immutability of blockchain and the lack of best practices for properly designing and developing smart contracts, it is crucial to assure smart contract quality before deployment. With the help of an exploratory survey involving developers and researchers, this paper identifies the practices and tools used to develop, implement, and evaluate smart contracts. The survey received 55 valid responses. Such responses indicate that (i) inefficiencies may occur during the development cycle of a smart contract, especially regarding requirements specification, design, and testing phases, and (ii) the lack of a shared standard to evaluate the functional quality of implemented smart contracts. To start coping with these issues, the adoption of functional suitability assessment measures recommended by the ISO/IEC 25000 standard, widely used in software engineering, is proposed by adapting them to the context of smart contracts. Through some examples, the manuscript also illustrates how to measure the functional completeness and correctness of smart contracts. The proposed procedure to measure smart contract functional suitability brings advantages to both developers and users of decentralized finance or non‐fungible tokens platforms, data marketplaces, or shipping and real estate services, just to mention a few. In particular, it helps (i) better outline the responsibilities of smart contracts, (ii) uncover errors and deficiencies of smart contracts in the early stages, and (iii) ensure that the established requirements are met.

Unmanned Aerial Vehicles (UAVs) are nowadays used in a variety of applications. Given the cyber-physical nature of UAVs, software defects in these systems can cause issues with safety-critical implications. An important aspect of the lifecycle of UAV software is to minimize the possibility of harming humans or damaging properties through a continuous process of hazard identification and safety risk management. Specifically, safety-related concerns typically emerge during the operation of UAV systems, reported by end-users and developers in the form of issue reports and pull requests. However, popular UAV systems daily receive tens or hundreds of reports of varying types and quality. To help developers timely identify and triage safety-critical UAV issues, we (i) experiment with automated approaches (previously used for issue classification) for detecting the safety-related matters appearing in the titles and descriptions of issues and pull requests reported in UAV platforms and (ii) propose a categorization of the main hazards and accidents discussed in such issues. Our results (i) show that shallow machine learning (ML)-based approaches can identify safety-related sentences with precision, recall, and F-measure values of about 80%; and (ii) provide a categorization and description of the relationships between safety issue hazards and accidents.

Blockchain technology is becoming increasingly popular, and smart contracts (i.e., programs that run on top of the blockchain) represent a crucial element of this technology. In particular, smart contracts running on Ethereum (i.e., one of the most popular blockchain platforms) are often developed with Solidity, and their deployment and execution consume gas (i.e., a fee compensating the computing resources required). Smart contract development frequently involves code reuse, but poor readable smart contracts could hinder their reuse. However, writing readable smart contracts is challenging, since practices for improving the readability could also be in contrast with optimization strategies for reducing gas consumption. This paper aims at better understanding (i) the readability aspects for which traditional software and smart contracts differ, and (ii) the specific smart contract readability features exhibiting significant relationships with gas consumption. We leverage a set of metrics that previous research has proven correlated with code readability. In particular, we first compare the values of these metrics obtained for both Solidity smart contracts and traditional software systems (written in Java). Then, we investigate the correlations occurring between these metrics and gas consumption and between each pair of metrics. The results of our study highlight that smart contracts usually exhibit lower readability than traditional software for what concerns the number of parentheses, inline comments, and blank lines used. In addition, we found some readability metrics (such as the average length of identifiers and the average number of keywords) that significantly correlate with gas consumption.

With behavior-driven development (BDD), domain experts describe system behavior and desired outcomes through natural language-like sentences, e.g., using the Gherkin language. BDD frameworks partially convert the content of Gherkin specifications into executable test code. Previous studies have reported several issues with the current BDD practice, for example long repetitive Gherkin specifications and slow-running test suites. Data tables and additional features were added to the Gherkin syntax to express compactly test inputs (e.g., provide different combinations of input values and desired outputs to run tests multiple times) and also to improve the readability of Gherkin files (henceforth called spec files). However, there is no empirical evidence about the actual usage of these Gherkin features. To fill this gap, we analyzed the content of 1,572 spec files extracted from 23 open-source projects. For each spec file, we collected a set of metrics modeling the structure and the usage of the different Gherkin features. We found that only a minority of the considered spec files (i.e., 590) used data tables that contain two rows, on average. We also used statistical tests to compare the contents of spec files with and without data tables and found significant differences between the two populations, especially for what concerns the number of lines of code (LoC). On the one hand, our results shed some light on the discrepancies between the recommendations for defining Gherkin specifications and their actual adoption in practice. On the other hand, our findings demonstrate that the adoption of additional features, such as data tables, might only partially help to reduce the length of Gherkin specifications.

Remediation to a software vulnerability can be accomplished either by the developer who introduced it or by a different one. In this context, we refer to a self-fixed vulnerability when the fixing is carried out by the developer who introduced it. Previous research demonstrated that a developer who introduces a bug is also the best candidate to fix it. However, as vulnerabilities conceptually differ from non-security bugs and specific skills and knowledge are required for solving them, it is unclear if the previous finding also applies to vulnerabilities or specific vulnerability types. To fill this gap, in this paper, we investigate the diffusion of self-fixed vulnerabilities within software projects, the types of vulnerabilities that are more prone to self-fixing, and the time required to solve self-fixed vulnerabilities compared to non-self-fixed ones. Specifically, we analyzed 1,752 commits related to C and PHP open-source projects aimed at fixing (or self-fixing) vulnerabilities spanning 17 different types of software weaknesses. The results of our study show that 20.55% of the considered vulnerabilities in C projects and 36.46% of the considered vulnerabilities in PHP projects are self-fixed. In addition, the average remediation time of self-fixed vulnerabilities is generally shorter than non-self-fixed ones. In particular, in C projects, self-fixed integer overflow vulnerabilities are patched about 5 times shorter than non-self-fixed ones, while vulnerabilities related to improper calculation or conversion of numbers are generally fixed faster by other developers. Similarly, in PHP projects, CSRF vulnerabilities tend to be patched in a shorter time when they are self-fixed, while unauthorized access vulnerabilities are likely repaired faster by other developers. Our results can help both researchers and practitioners identifying the best candidates to solve specific vulnerability bugs.

Social bots are computer algorithms able to produce content and interact with other users on social media autonomously, trying to emulate and possibly influence humans’ behavior. Indeed, bots are largely employed for malicious purposes, like spreading disinformation and conditioning electoral campaigns. Nowadays, bots’ capability of emulating human behaviors has become increasingly sophisticated, making their detection harder. In this paper, we aim at recognizing bot-driven accounts by evaluating the consistency of users’ writing style over time. In particular, we leverage the intuition that while bots compose posts according to fairly deterministic processes, humans are influenced by subjective factors (e.g., emotions) that can alter their writing style. To verify this assumption, by using stylistic consistency indicators, we characterize the writing style of more than 12,000 among bot-driven and human-operated Twitter accounts and find that statistically significant differences can be observed between the different types of users. Thus, we evaluate the effectiveness of different machine learning (ML) algorithms based on stylistic consistency features in discerning between human-operated and bot-driven Twitter accounts and show that the experimented ML algorithms can achieve high performance (i.e., F-measure values up to 98%) in social bot detection tasks.

Blockchain is increasingly revolutionizing a variety of sectors, from finance to healthcare. Indeed, the availability of public blockchain platforms, such as Ethereum, has stimulated the development of hundreds of decentralized apps (dApps) that combine smart contract(s) and a front-end user interface. Smart contracts are software, as well, and, as traditional software, they require to be developed and maintained or evolved. Among all the quality properties that must be assessed and guaranteed, readability is a key aspect of source code: a highly readable code facilitates its maintainability, portability, and reusability. This is especially true when considering smart contracts, where code reuse is widely adopted. Indeed, smart contract developers often integrate code portions from other smart contracts in their artifacts. To help developers and researchers more easily estimating and monitoring the code readability of smart contracts, in this demo, we present iSCREAM. iSCREAM automatically inspects Solidity smart contracts and computes a set of metrics that previous research demonstrated being related to code readability. We evaluated iSCREAM on 90 real-world smart contract functions, showing that our tool correctly computes all the aforementioned metrics. Demo webpage: https://github.com/mfredella/iSCREAM

Software developers rely on various repositories and communication channels to exchange relevant information about their ongoing tasks and the status of overall project progress. In this context, semi-structured and unstructured software artifacts have been leveraged by researchers to build recommender systems aimed at supporting developers in different tasks, such as transforming user feedback in maintenance and evolution tasks, suggesting experts, or generating software documentation. More specifically, Natural Language (NL) parsing techniques have been successfully leveraged to automatically identify (or extract) the relevant information embedded in unstructured software artifacts. However, such techniques require the manual identification of patterns to be used for classification purposes. To reduce such a manual effort, we propose an NL parsing-based tool for software artifacts analysis named NEON that can automate the mining of such rules, minimizing the manual effort of developers and researchers. Through a small study involving human subjects with NL processing and parsing expertise, we assess the performance of NEON in identifying rules useful to classify app reviews for software maintenance purposes. Our results show that more than one-third of the rules inferred by NEON are relevant for the proposed task. Demo webpage: https://github.com/adisorbo/NEON_tool

: Addressing user requests in the form of bug reports and Github issues represents a crucial task of any successful software project. However, user-submitted issue reports tend to widely differ in their quality, and developers spend a considerable amount of time handling them. : By collecting a dataset of around 6,000 issues of 279 GitHub projects, we observe that developers take significant time (i.e., about five months, on average) before labeling an issue as a wontfix. For this reason, in this paper, we empirically investigate the nature of wontfix issues and methods to facilitate issue management process. : We first manually analyze a sample of 667 wontfix issues, extracted from heterogeneous projects, investigating the common reasons behind a “wontfix decision”, the main characteristics of wontfix issues and the potential factors that could be connected with the time to close them. Furthermore, we experiment with approaches enabling the prediction of wontfix issues by analyzing the titles and descriptions of reported issues when submitted. : Our investigation sheds some light on the wontfix issues’ characteristics, as well as the potential factors that may affect the time required to make a “wontfix decision”. Our results also demonstrate that it is possible to perform prediction of wontfix issues with high average values of precision, recall, and F-measure (90%–93%).

Most software maintenance and evolution tasks require developers to understand the source code of their software systems. Software developers usually inspect class comments to gain knowledge about program behavior, regardless of the programming language they are using. Unfortunately, (i) different programming languages present language-specific code commenting notations and guidelines; and (ii) the source code of software projects often lacks comments that adequately describe the class behavior, which complicates program comprehension and evolution activities. To handle these challenges, this paper investigates the different language-specific class commenting practices of three programming languages: Python, Java, and Smalltalk. In particular, we systematically analyze the similarities and differences of the information types found in class comments of projects developed in these languages. We propose an approach that leverages two techniques – namely Natural Language Processing and Text Analysis – to automatically identify class comment types, i.e., the specific types of semantic information found in class comments. To the best of our knowledge, no previous work has provided a comprehensive taxonomy of class comment types for these three programming languages with the help of a common automated approach. Our results confirm that our approach can classify frequent class comment information types with high accuracy for the Python, Java, and Smalltalk programming languages. We believe this work can help in monitoring and assessing the quality and evolution of code comments in different programming languages, and thus support maintenance and evolution tasks.

Abstract App quality impacts user experience and satisfaction. As a consequence, both app ratings and user feedback reported in app reviews are directly influenced by the user‐perceived app quality. Through an empirical study involving 210,517 reviews related to 317 Android apps, in this paper, we experiment with the combined usage of app rating and user reviews analysis (i) to investigate the most important factors influencing the perceived app quality, (ii) focusing on the topics discussed in user review that most relate with app rating. Besides, we investigate whether specific code quality metrics could be monitored to prevent the rising of negative user feedback (i.e., types of user review comments), connected with low ratings. Our study demonstrates that user comments reporting bugs are negatively correlated with the rating, while reviews reportingfeature requests do not. Interestingly, depending on the app category, we observed that different kinds of issues have rather different relationships with the rating and the user‐perceived quality of the app. In particular, we observe that for specific app categories (e.g., communication), some code quality factors have significant relationships with the raising of certain types of feedback, which, in turn, are negatively connected with app ratings.

Communication means, such as issue trackers, mailing lists, Q&A forums, and app reviews, are premier means of collaboration among developers, and between developers and end-users. Analyzing such sources of information is crucial to build recommenders for developers, for example suggesting experts, re-documenting source code, or transforming user feedback in maintenance and evolution strategies for developers. To ease this analysis, in previous work we proposed Development Emails Content Analyzer (DECA), a tool based on Natural Language Parsing that classifies with high precision development emails' fragments according to their purpose. However, DECA has to be trained through a manual tagging of relevant patterns, which is often effort-intensive, error-prone and requires specific expertise in natural language parsing. In this paper, we first show, with an empirical study, the extent to which producing rules for identifying such patterns requires effort, depending on the nature and complexity of patterns. Then, we propose an approach, named Nlp-based softwarE dOcumentation aNalyzer (NEON), that automatically mines such rules, minimizing the manual effort. We assess the performances of NEON in the analysis and classification of mobile app reviews, developers discussions, and issues. NEON simplifies the patterns identification and rules definition processes, allowing a savings of more than 70 percent of the time otherwise spent on performing such activities manually. Results also show that NEON-generated rules are close to the manually identified ones, achieving comparable recall.

Pull requests (PRs) selection is a challenging task faced by integrators in pull-based development (PbD), with hundreds of PRs submitted on a daily basis to large open-source projects. Managing these PRs manually consumes integrators' time and resources and may lead to delays in the acceptance, response, or rejection of PRs that can propose bug fixes or feature enhancements. On the one hand, well-known platforms for performing PbD, like GitHub, do not provide built-in recommendation mechanisms for facilitating the management of PRs. On the other hand, prior research on PRs recommendation has focused on the likelihood of either a PR being accepted or receive a response by the integrator. In this paper, we consider both those likelihoods, this to help integrators in the PRs selection process by suggesting to them the appropriate actions to undertake on each specific PR. To this aim, we propose an approach, called CARTESIAN (aCceptance And Response classificaTion-based requESt IdentificAtioN) modeling the PRs recommendation according to PR actions. In particular, CARTESIAN is able to recommend three types of PR actions: accept, respond, and reject. We evaluated CARTESIAN on the PRs of 19 popular GitHub projects. The results of our study demonstrate that our approach can identify PR actions with an average precision and recall of about 86%. Moreover, our findings also highlight that CARTESIAN outperforms the results of two baseline approaches in the task of PRs selection.

Software maintenance is crucial for software projects evolution and success: code should be kept up-to-date and error-free, this with little effort and continuous updates for the end-users. In this context, issue trackers are essential tools for creating, managing and addressing the several (often hundreds of) issues that occur in software systems. A critical aspect for handling and prioritizing issues involves the assignment of labels to them (e.g., for projects hosted on GitHub), in order to determine the type (e.g., bug report, feature request and so on) of each specific issue. Although this labeling process has a positive impact on the effectiveness of issue processing, the current labeling mechanism is scarcely used on GitHub. In this demo, we introduce a tool, called Ticket Tagger, which leverages machine learning strategies on issue titles and descriptions for automatically labeling GitHub issues. Ticket Tagger automatically predicts the labels to assign to issues, with the aim of stimulating the use of labeling mechanisms in software projects, this to facilitate the issue management and prioritization processes. Along with the presentation of the tool's architecture and usage, we also evaluate its effectiveness in performing the issue labeling/classification process, which is critical to help maintainers to keep control of their workloads by focusing on the most critical issue tickets.

Private and sensitive information is often revealed in posts appearing in Social Networks (SN). This is due to the users' willingness to increase their interactions within specific social groups, but also to a poor knowledge about the risks for privacy. We argue that technologies able to evaluate the sensitiveness of information while it is being published could enhance privacy protection by warning the user about the risks deriving from the disclosure of a certain information. To this aim, we propose a method, and an accompanying tool, to automatically intercept the sensitive information which is delivered in a social network post, through the exploitation of recurrent natural language patterns that are often used by users to disclose private data. A comparison with several machine learning techniques reveals that our method outperforms them, since it is more precise, accurate and not dependent on (i) a specific training set, or (ii) the selection of particular features.

Abstract In the context of software engineering, product software quality measures how well a software artifact is designed and coded. Software products must satisfy nonfunctional properties (eg, reliability, usability, understandability, and maintainability), in order to make maintenance and evolution sustainable in the long period. Software evolution is an issue of interest for the malware writers, too, for 2 reasons. First, to evade detection with the minimum effort, malware writers use to produce “variants,” which are obtained by applying little changes to existing malware. Morevoer, recent studies demonstrated that malware is increasingly improving evasion strategies and infection mechanisms and is using more and more complex payloads. This suggests that malware writers are devoting relevant efforts and skills for producing high‐quality software. For this reason, we wonder whether malware writers are devoting effort to improve the structural quality of their code, too, as it happens in the development of goodware. To investigate this question, we (1) characterize a dataset containing about 20 000 Android applications, divided into goodware and malware ones, relying on the Android API version they require, and (2) compute software quality metrics, divided into 4 categories (ie, dimensional, complexity, object‐oriented, and Android‐oriented metrics) for apps belonging to each population. We then identify evolution trends of these metrics in malware and goodware. The results of our study demonstrate that goodware and malicious applications exhibit similar evolution trends for some of the quality indicators, suggesting that malware writers care about the overall quality of their code. Code quality could be considered an indirect measure of how many and how fast variants of existing malware will be released in the wild.

Google Play, Apple App Store and Windows Phone Store are well known distribution platforms where users can download mobile apps, rate them and write review comments about the apps they are using. Previous research studies demonstrated that these reviews contain important information to help developers improve their apps. However, analyzing reviews is challenging due to the large amount of reviews posted every day, the unstructured nature of reviews and its varying quality.

Mobile app developers constantly monitor feedback in user reviews with the goal of improving their mobile apps and better meeting user expectations. Thus, automated approaches have been proposed in literature with the aim of reducing the effort required for analyzing feedback contained in user reviews via automatic classification/prioritization according to specific topics. In this paper, we introduce SURF (Summarizer of User Reviews Feedback), a novel approach to condense the enormous amount of information that developers of popular apps have to manage due to user feedback received on a daily basis. SURF relies on a conceptual model for capturing user needs useful for developers performing maintenance and evolution tasks. Then it uses sophisticated summarisation techniques for summarizing thousands of reviews and generating an interactive, structured and condensed agenda of recommended software changes. We performed an end-to-end evaluation of SURF on user reviews of 17 mobile apps (5 of them developed by Sony Mobile), involving 23 developers and researchers in total. Results demonstrate high accuracy of SURF in summarizing reviews and the usefulness of the recommended changes. In evaluating our approach we found that SURF helps developers in better understanding user needs, substantially reducing the time required by developers compared to manually analyzing user (change) requests and planning future software changes.

App Stores, such as Google Play or the Apple Store, allow users to provide feedback on apps by posting review comments and giving star ratings. These platforms constitute a useful electronic mean in which application developers and users can productively exchange information about apps. Previous research showed that users feedback contains usage scenarios, bug reports and feature requests, that can help app developers to accomplish software maintenance and evolution tasks. However, in the case of the most popular apps, the large amount of received feedback, its unstructured nature and varying quality can make the identification of useful user feedback a very challenging task. In this paper we present a taxonomy to classify app reviews into categories relevant to software maintenance and evolution, as well as an approach that merges three techniques: (1) Natural Language Processing, (2) Text Analysis and (3) Sentiment Analysis to automatically classify app reviews into the proposed categories. We show that the combined use of these techniques allows to achieve better results (a precision of 75% and a recall of 74%) than results obtained using each technique individually (precision of 70% and a recall of 67%).

Written development communication (e.g. mailing lists, issue trackers) constitutes a precious source of information to build recommenders for software engineers, for example aimed at suggesting experts, or at redocumenting existing source code. In this paper we propose a novel, semi-supervised approach named DECA (Development Emails Content Analyzer) that uses Natural Language Parsing to classify the content of development emails according to their purpose (e.g. feature request, opinion asking, problem discovery, solution proposal, information giving etc), identifying email elements that can be used for specific tasks. A study based on data from Qt and Ubuntu, highlights a high precision (90%) and recall (70%) of DECA in classifying email content, outperforming traditional machine learning strategies. Moreover, we successfully used DECA for re-documenting source code of Eclipse and Lucene, improving the recall, while keeping high precision, of a previous approach based on ad-hoc heuristics.