mgaughan/adaptation-slr
1
0
Fork 0
Code

11/34 coded

Browse Source
This commit is contained in:
mgaughan 2025-07-14 11:04:19 -04:00
parent c37ed9aaa8
commit 6aecc5f5d8
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

@ -7,7 +7,7 @@ M6PP5MPQ,conferencePaper,2011,"Jensen, Chris; Scacchi, Walt",License Update and
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,,,,,
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,,,,,
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,,,,,
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"
JL6YZE5S,journalArticle,2023,"Hu, Jin; Hu, Daning; Yang, Xuan; Chau, Michael",The impacts of lockdown on open source software contributions during the COVID-19 pandemic,10.1016/j.respol.2023.104885,,,,,
XPC3Y8HH,journalArticle,2020,"Butler, Simon; Gamalielsson, Jonas; Lundell, Bjorn; Brax, Christoffer; Mattsson, Anders; Gustaysson, Tomas; Feist, Jonas; Lonroth, Erik",Maintaining interoperability in open source software: A case study of the Apache PDFBox project,10.1016/j.jss.2019.110452,,,,,
4V42NWTT,journalArticle,2016,"Adams, Bram; Kavanagh, Ryan; Hassan, Ahmed E.; German, Daniel M.",An empirical study of integration activities in distributions of open source software,10.1007/s10664-015-9371-y,,,,,

1 Key Item Type Publication Year Author Title DOI Change characteristics (blue) Actors (purple) Environmental characteristics (green) Methods details (orange) Misc. (red)
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
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
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
11 JL6YZE5S journalArticle 2023 Hu, Jin; Hu, Daning; Yang, Xuan; Chau, Michael The impacts of lockdown on open source software contributions during the COVID-19 pandemic 10.1016/j.respol.2023.104885
12 XPC3Y8HH journalArticle 2020 Butler, Simon; Gamalielsson, Jonas; Lundell, Bjorn; Brax, Christoffer; Mattsson, Anders; Gustaysson, Tomas; Feist, Jonas; Lonroth, Erik Maintaining interoperability in open source software: A case study of the Apache PDFBox project 10.1016/j.jss.2019.110452
13 4V42NWTT journalArticle 2016 Adams, Bram; Kavanagh, Ryan; Hassan, Ahmed E.; German, Daniel M. An empirical study of integration activities in distributions of open source software 10.1007/s10664-015-9371-y