mgaughan/adaptation-slr
1
0
Fork 0
Code

28/34

Browse Source
This commit is contained in:
mgaughan 2025-07-25 00:49:51 -04:00
parent cd2a10e621
commit 3fbc12447f
1 changed files with 1 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
070725_papers_master.csv
View File

@ -4,7 +4,7 @@ KUWLMFWM,journalArticle,2017,"Santos, Carlos Denner D60os",Changes in free and o
SJEI288C,conferencePaper,2024,"Franke, Lucas; Liang, Huayu; Farzanehpour, Sahar; Brantly, Aaron; Davis, James C.; Brown, Chris",An Exploratory Mixed-methods Study on General Data Protection Regulation (GDPR) Compliance in Open-Source Software,10.1145/3674805.3686692,technical and organizational/procedural: broad compliance with GDPR; increased development work and attention devoted to compliance with GDPR features and PRs -- increases to the technical management of data --- organizational: slowed down development timelines immensely --- organization: GDPR compliance requires and overhaul of --- consultation with legal team is a change in and of itself ; one that decreased productivity; technical because the technical aspects of the code were the things regulated by GDPR,OSS project developers --- some of whom had submitted GDPR compliance Prs ,"geopolitical legal regulation --- data privacy and rights regulation --- EU --- from a technical level, this is a non-functional requirement ---internal evaluation of change success within environment: consultation with legal counsel --- self-assessment --- “most of the resources on the internet are wrong”","Mixed-methods: pilot interview study with three developers; survey with 56 developers; mined Prs from GitHub, some sampling for survey done from activity data mined from GitHub ; grounded thematic coding methods for analysis of free responses/qualitative themes","developers not happy about compliance --- frustration of internal productivity in order to comply with the standard--- unhappiness also with the standard itself, not just what the compliance does to the project"
U7U4YLVB,journalArticle,2023,"Hsieh, Jane; Kim, Joselyn; Dabbish, Laura; Zhu, Haiyi","""Nip it in the Bud"": Moderation Strategies in Open Source Software Projects and the Role of Bots",10.1145/3610092,"Procedural – moderation strategies in response to misconduct by contributors from GitHub; rationale to address influx of activity or misconduct -- organizing formal moderation teams within the project -- when the projects get popular and large, formal moderation teams follow to address misconduct; in both organizational structure and moderation strategy, OSS projects adapt their procedure to match the demands of contributor misconduct","moderators or maintainers of 10 open source projects, these projects have varying sizes --- 13 men and 1 women; these are maintainers or moderators within projects, meaning that they are relatively priveliged and higher up in the governance of the library","GitHub as a hosting platform for different open source projects --- the environment consists of internal project collaborators and external (non-collaborator) contributors. The platform of GitHub expands the scope of work that project maintainers are tasked with doing. Project maintainers must now handle the chores of managing new contributors and moderating discussions The platformed nature of GitHub supports contributor misconduct, as different external contributors are drawn to projects without fully understanding their implications. T","qualitative interviews with 14 developers who moderate or maintain projects with ranging sizes semi-structured interviews, transcripts were anlayzed using bottom-up, thematic analysis of the interviews. specified bottom-up affinity coding before code and theme synthesis into common themes and traits","Not even looking at procedural changes around technical labor, instead looking at procedural changes around non-technical labor -- this is similar to the Geiger paper; Sometimes the project tries to explicitly and intentionally change the environment. e.g. reporting misconduct-ing users to GitHub the platform as a way to minimize the impact of misconduct users to the project"
M6PP5MPQ,conferencePaper,2011,"Jensen, Chris; Scacchi, Walt",License Update and Migration Processes in Open Source Software Projects,https://doi.org/10.1007/978-3-642-24418-6_12,"Procedural – the adoption of a new contributor license agreement in a sponsored OSS project (NetBeans); the change also looks at the creation of a new license in Apache but because that takes place higher up than the project level, that is less relevant to this paper. Self evaluation of the success of the adaptive change is done before-hand by the Sun legal team; no real empirical evaluation in regards to the project environment. ","Employees at the sponsoring organization. NetBeans was sponsored by Sun Microsystems, so the discussion around the adoption of a new SLA and the language around the license were primarily litigated by Sun legal and Sun engineers, much to the chagrin of other contributors in the NetBeans project",American legal ecosystem and tort law. “Sun required full copyright authority to protect the NetBeans project from legal threats and provide Sun with the flexibility to adapt the NetBeans license over time.” affording the contributor as well as Sun independent copyright to the contributed source software,"qualitative case study; looking through the mailing list discussions surrounding the license changes, they built a bespoke piece of labeling software to look at the different themes within the messages as well as using more established CAQDAS methods for identifying emergent themes. ",pre-figuring adaptive change down the road received push-back from the community --- same thing happened in Apache but received less push back maybe because of community-based rationale and view of Apache
ENQ5AACF,journalArticle,2022,"Barcomb, Ann; Klaas-Jan Stol; Fitzgerald, Brian; Riehle, Dirk",Managing Episodic Volunteers in Free/Libre/Open Source Software Communities,10.1109/TSE.2020.2985093,,,,,
ENQ5AACF,journalArticle,2022,"Barcomb, Ann; Klaas-Jan Stol; Fitzgerald, Brian; Riehle, Dirk",Managing Episodic Volunteers in Free/Libre/Open Source Software Communities,10.1109/TSE.2020.2985093,procedural -- -the management of episodic volunteers within FLOSS communities; concerns with EV -> worries about how the shape of the environment will impact the project’s knowledge transfer and development. There are 65 practices that community managers adopt to manage EV contributions ranging from preparing the engaged community to restructuring project governance ,FLOSS community managers of BIG OSS projects and ecosystems and communities; sampled through a variety of specific and targeted ways. one-third of them female,"Immediate environment --- episodic volunteers who circulate around the project, infrequently but consistently contributing --- these episodic contributors shape how the project operates and its organization --- but aren’t quite a part of the project; In this, there’s an interesting litigation of the porous-ness of the FLOSS project, without specific inclusion/exclusion rights, there’s very little keeping things together besides shared goals; Many of the concerns with EV participation are rooted in the concerns around the integration of EVs into the full-membership of the project. the community managers are worried about the ways that community managers may continue to be marginalized","qualitative --- policy Delphi study (set of interviews with experts in the field) 24 community managers from 22 different FLOSS communities/projects Delphi method developed to arrive at consensus amongst a group of experts for how things /should/ go; policy Delphi method was developed to study specific arguments and positions, rather than consensus brainstorming -> enriching -> refining. generating concerns and perspectives; developing them, then polishing for the production of the final set of themes, practices and ideas","65 practices actually have very little description of how many projects use them or how widely adopted these practices are across different kinds of settings. I’m still not so happy about the lack of /REAL/ empirics here--- yes the opinions of the different experts are good and useful, but they leave a lot of information about how these projects ACTUALLY use practices to address EV on the floor"
RN5Y3TN5,conferencePaper,2020,"Wessel, Mairieli; Serebrenik, Alexander; Wiese, Igor; Steinmacher, Igor; Gerosa, Marco A.",What to Expect from Code Review Bots on GitHub? A Survey with OSS Maintainers,10.1145/3422392.3422459,organizational/procedural - adoption of code review bot; rationale: this code review bot will enhance feedback to developers contributing code; reducing maintainers effort when evaluating different parts of the code,OSS maintainers of projects that had adopted code review bots ,external/peripheral contributions from the fork of the project --- those waiting for code review --- self-assessment: internal metrics of amorphous normative goals such as reducing time to close on Prs; maintainers hoped to automate things as the number of contributions increased,qualitative survey: 27 maintainers re: the adoption of code review bots within the project. maintainers for projects who had adopted at least one code review bot. using the GHTorrent data set and who had contributed on either side of bot adoption --- card sorting thematic analysis of the survey responses --- discussion and consensus regarding the themes,a lot of internal rationalization when addressing different factors of being more ‘productive’ or lessening small labor within the project--- added noise and downside results from the adoption of the bots
HS8AQN5V,journalArticle,2010,"Sojer, Manuel; Henkel, Joachim","Code Reuse in Open Source Software Development: Quantitative Evidence, Drivers, and Impediments",10.17705/1jais.00248,"technical- copy based reuse of projects and their code: rationale is the continuation of effective, efficient, and quality code; rationale that reuse makes the code more stable and compatible with standards; primary reasons developers don’t reuse more code is that there are few reusable resources for the current project/code search issues ",OSS developers on SourceForge; largely well-educated European Men in their 20s and 30s; who are very engaged in OSS networks and work,"Broader OSS environment of like projects or projects that are useful to the focal project because of adherence to standards, or quality thresholds; developer environment of SourceForge projects","mixed-methods; preliminary qualitative pilot interview study with 12 OSS developers, followed up with quantitative survey with 686 OSS developers quantitative survey with 686 OSS developers --- multivariate analyses of developers’ reuse behaviors; circulated survey on SourceForge to 7500 developers, asking for OSS developers’ input","Paper seems to be cosigning copy-based reuse as a useful way of building up OSS and constructing the project; Overly verbose article, did not need to be 46 pages, could have been far less Survey happens in 2009 Asking users to self-report hours spent on OSS seems lossy; but they are really attached to the method of using a lot of different statistical tests to go ‘establish validity’ of their studies"
GGZV58MQ,journalArticle,2021,"Klug, Daniel; Bogart, Christopher; Herbsleb, James D.","""They Can Only Ever Guide"": How an Open Source Software Community Uses Roadmaps to Coordinate Effort",10.1145/3449232,"procedural --- Use of project roadmaps --- ecosystem/project (porous distinction between the two) grows larger, with different stakeholders and goals --- to organize this (identifying consensus around project goals) roadmaps are used to structure things -- articulated work for the core members of the project ; team members followed the guide far more than other contributors -- goal of the roadmap is to make the trajectory more visible for external parties; 5.1.4; the roadmap is critical for helping communicate work to external parties, to help users plan,","maybe the change is especially relevant for core team members --- for them the roadmap structures their priorities and aims; OSS contributors to the Rust project, either core (contributing to blog posts or team members) or more peripheral (have committed to the compiler project)","infrastructural OSS  ecosystem, the Rust programming language ecosystem. --- the road-mapping architecture occurs across the ecosystem, encapsulating different repositories within the Rust project",mixed methods single case study and email interviews --- selection of a \`revelatory case’ for Rust and its roadmap evolution ; collected multimodal data across settings and then followed up with Rust contributors to try to contextualize finidngs/observations;sampled for email interview from the core develoeprs identified through data mining (2018 road map); always ends up with qual coding/analysis for the text data --- more rigorously inductive than computational approaches,"there’s a difference in the roadmap’s presentation/ostensible utility and its utility in practice --- while it seems lo be a top-down directive, in fact it is a reflection of bottom-up interest and labor promises; litany of rationales and motivations for the creation of the roadmap, environmental pressures and inputs are only one part of that. so many internal reasons, change is not often articulated in terms of the external pressures, instead the self-organization of tings is useful for structuring the different feature developments; adaptive change (roadmap) does not occur in a vacuum, it needs to be cultivated and supported through the other documents like READMEs or GOVERNANCE documents;  the roadmapping architecture enc"

1 Key Item Type Publication Year Author Title DOI Change characteristics (blue) Actors (purple) Environmental characteristics (green) Methods details (orange) Misc. (red)
4 SJEI288C conferencePaper 2024 Franke, Lucas; Liang, Huayu; Farzanehpour, Sahar; Brantly, Aaron; Davis, James C.; Brown, Chris An Exploratory Mixed-methods Study on General Data Protection Regulation (GDPR) Compliance in Open-Source Software 10.1145/3674805.3686692 technical and organizational/procedural: broad compliance with GDPR; increased development work and attention devoted to compliance with GDPR features and PRs -- increases to the technical management of data --- organizational: slowed down development timelines immensely --- organization: GDPR compliance requires and overhaul of --- consultation with legal team is a change in and of itself ; one that decreased productivity; technical because the technical aspects of the code were the things regulated by GDPR OSS project developers --- some of whom had submitted GDPR compliance Prs geopolitical legal regulation --- data privacy and rights regulation --- EU --- from a technical level, this is a non-functional requirement ---internal evaluation of change success within environment: consultation with legal counsel --- self-assessment --- “most of the resources on the internet are wrong” Mixed-methods: pilot interview study with three developers; survey with 56 developers; mined Prs from GitHub, some sampling for survey done from activity data mined from GitHub ; grounded thematic coding methods for analysis of free responses/qualitative themes developers not happy about compliance --- frustration of internal productivity in order to comply with the standard--- unhappiness also with the standard itself, not just what the compliance does to the project
5 U7U4YLVB journalArticle 2023 Hsieh, Jane; Kim, Joselyn; Dabbish, Laura; Zhu, Haiyi "Nip it in the Bud": Moderation Strategies in Open Source Software Projects and the Role of Bots 10.1145/3610092 Procedural – moderation strategies in response to misconduct by contributors from GitHub; rationale to address influx of activity or misconduct -- organizing formal moderation teams within the project -- when the projects get popular and large, formal moderation teams follow to address misconduct; in both organizational structure and moderation strategy, OSS projects adapt their procedure to match the demands of contributor misconduct moderators or maintainers of 10 open source projects, these projects have varying sizes --- 13 men and 1 women; these are maintainers or moderators within projects, meaning that they are relatively priveliged and higher up in the governance of the library GitHub as a hosting platform for different open source projects --- the environment consists of internal project collaborators and external (non-collaborator) contributors. The platform of GitHub expands the scope of work that project maintainers are tasked with doing. Project maintainers must now handle the chores of managing new contributors and moderating discussions The platformed nature of GitHub supports contributor misconduct, as different external contributors are drawn to projects without fully understanding their implications. T qualitative interviews with 14 developers who moderate or maintain projects with ranging sizes semi-structured interviews, transcripts were anlayzed using bottom-up, thematic analysis of the interviews. specified bottom-up affinity coding before code and theme synthesis into common themes and traits Not even looking at procedural changes around technical labor, instead looking at procedural changes around non-technical labor -- this is similar to the Geiger paper; Sometimes the project tries to explicitly and intentionally change the environment. e.g. reporting misconduct-ing users to GitHub the platform as a way to minimize the impact of misconduct users to the project
6 M6PP5MPQ conferencePaper 2011 Jensen, Chris; Scacchi, Walt License Update and Migration Processes in Open Source Software Projects https://doi.org/10.1007/978-3-642-24418-6_12 Procedural – the adoption of a new contributor license agreement in a sponsored OSS project (NetBeans); the change also looks at the creation of a new license in Apache but because that takes place higher up than the project level, that is less relevant to this paper. Self evaluation of the success of the adaptive change is done before-hand by the Sun legal team; no real empirical evaluation in regards to the project environment. Employees at the sponsoring organization. NetBeans was sponsored by Sun Microsystems, so the discussion around the adoption of a new SLA and the language around the license were primarily litigated by Sun legal and Sun engineers, much to the chagrin of other contributors in the NetBeans project American legal ecosystem and tort law. “Sun required full copyright authority to protect the NetBeans project from legal threats and provide Sun with the flexibility to adapt the NetBeans license over time.” affording the contributor as well as Sun independent copyright to the contributed source software qualitative case study; looking through the mailing list discussions surrounding the license changes, they built a bespoke piece of labeling software to look at the different themes within the messages as well as using more established CAQDAS methods for identifying emergent themes. pre-figuring adaptive change down the road received push-back from the community --- same thing happened in Apache but received less push back maybe because of community-based rationale and view of Apache
7 ENQ5AACF journalArticle 2022 Barcomb, Ann; Klaas-Jan Stol; Fitzgerald, Brian; Riehle, Dirk Managing Episodic Volunteers in Free/Libre/Open Source Software Communities 10.1109/TSE.2020.2985093 procedural -- -the management of episodic volunteers within FLOSS communities; concerns with EV -> worries about how the shape of the environment will impact the project’s knowledge transfer and development. There are 65 practices that community managers adopt to manage EV contributions ranging from preparing the engaged community to restructuring project governance FLOSS community managers of BIG OSS projects and ecosystems and communities; sampled through a variety of specific and targeted ways. one-third of them female Immediate environment --- episodic volunteers who circulate around the project, infrequently but consistently contributing --- these episodic contributors shape how the project operates and its organization --- but aren’t quite a part of the project; In this, there’s an interesting litigation of the porous-ness of the FLOSS project, without specific inclusion/exclusion rights, there’s very little keeping things together besides shared goals; Many of the concerns with EV participation are rooted in the concerns around the integration of EVs into the full-membership of the project. the community managers are worried about the ways that community managers may continue to be marginalized qualitative --- policy Delphi study (set of interviews with experts in the field) 24 community managers from 22 different FLOSS communities/projects Delphi method developed to arrive at consensus amongst a group of experts for how things /should/ go; policy Delphi method was developed to study specific arguments and positions, rather than consensus brainstorming -> enriching -> refining. generating concerns and perspectives; developing them, then polishing for the production of the final set of themes, practices and ideas 65 practices actually have very little description of how many projects use them or how widely adopted these practices are across different kinds of settings. I’m still not so happy about the lack of /REAL/ empirics here--- yes the opinions of the different experts are good and useful, but they leave a lot of information about how these projects ACTUALLY use practices to address EV on the floor
8 RN5Y3TN5 conferencePaper 2020 Wessel, Mairieli; Serebrenik, Alexander; Wiese, Igor; Steinmacher, Igor; Gerosa, Marco A. What to Expect from Code Review Bots on GitHub? A Survey with OSS Maintainers 10.1145/3422392.3422459 organizational/procedural - adoption of code review bot; rationale: this code review bot will enhance feedback to developers contributing code; reducing maintainers effort when evaluating different parts of the code OSS maintainers of projects that had adopted code review bots external/peripheral contributions from the fork of the project --- those waiting for code review --- self-assessment: internal metrics of amorphous normative goals such as reducing time to close on Prs; maintainers hoped to automate things as the number of contributions increased qualitative survey: 27 maintainers re: the adoption of code review bots within the project. maintainers for projects who had adopted at least one code review bot. using the GHTorrent data set and who had contributed on either side of bot adoption --- card sorting thematic analysis of the survey responses --- discussion and consensus regarding the themes a lot of internal rationalization when addressing different factors of being more ‘productive’ or lessening small labor within the project--- added noise and downside results from the adoption of the bots
9 HS8AQN5V journalArticle 2010 Sojer, Manuel; Henkel, Joachim Code Reuse in Open Source Software Development: Quantitative Evidence, Drivers, and Impediments 10.17705/1jais.00248 technical- copy based reuse of projects and their code: rationale is the continuation of effective, efficient, and quality code; rationale that reuse makes the code more stable and compatible with standards; primary reasons developers don’t reuse more code is that there are few reusable resources for the current project/code search issues OSS developers on SourceForge; largely well-educated European Men in their 20s and 30s; who are very engaged in OSS networks and work Broader OSS environment of like projects or projects that are useful to the focal project because of adherence to standards, or quality thresholds; developer environment of SourceForge projects mixed-methods; preliminary qualitative pilot interview study with 12 OSS developers, followed up with quantitative survey with 686 OSS developers quantitative survey with 686 OSS developers --- multivariate analyses of developers’ reuse behaviors; circulated survey on SourceForge to 7500 developers, asking for OSS developers’ input Paper seems to be cosigning copy-based reuse as a useful way of building up OSS and constructing the project; Overly verbose article, did not need to be 46 pages, could have been far less Survey happens in 2009 Asking users to self-report hours spent on OSS seems lossy; but they are really attached to the method of using a lot of different statistical tests to go ‘establish validity’ of their studies
10 GGZV58MQ journalArticle 2021 Klug, Daniel; Bogart, Christopher; Herbsleb, James D. "They Can Only Ever Guide": How an Open Source Software Community Uses Roadmaps to Coordinate Effort 10.1145/3449232 procedural --- Use of project roadmaps --- ecosystem/project (porous distinction between the two) grows larger, with different stakeholders and goals --- to organize this (identifying consensus around project goals) roadmaps are used to structure things -- articulated work for the core members of the project ; team members followed the guide far more than other contributors -- goal of the roadmap is to make the trajectory more visible for external parties; 5.1.4; the roadmap is critical for helping communicate work to external parties, to help users plan, maybe the change is especially relevant for core team members --- for them the roadmap structures their priorities and aims; OSS contributors to the Rust project, either core (contributing to blog posts or team members) or more peripheral (have committed to the compiler project) infrastructural OSS  ecosystem, the Rust programming language ecosystem. --- the road-mapping architecture occurs across the ecosystem, encapsulating different repositories within the Rust project mixed methods single case study and email interviews --- selection of a \`revelatory case’ for Rust and its roadmap evolution ; collected multimodal data across settings and then followed up with Rust contributors to try to contextualize finidngs/observations;sampled for email interview from the core develoeprs identified through data mining (2018 road map); always ends up with qual coding/analysis for the text data --- more rigorously inductive than computational approaches there’s a difference in the roadmap’s presentation/ostensible utility and its utility in practice --- while it seems lo be a top-down directive, in fact it is a reflection of bottom-up interest and labor promises; litany of rationales and motivations for the creation of the roadmap, environmental pressures and inputs are only one part of that. so many internal reasons, change is not often articulated in terms of the external pressures, instead the self-organization of tings is useful for structuring the different feature developments; adaptive change (roadmap) does not occur in a vacuum, it needs to be cultivated and supported through the other documents like READMEs or GOVERNANCE documents;  the roadmapping architecture enc