mgaughan/adaptation-slr
1
0
Fork 0
Code

27/34

Browse Source
This commit is contained in:
mgaughan 2025-07-24 14:30:56 -04:00
parent 72d3e10aea
commit cd2a10e621
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

@ -2,7 +2,7 @@ Key,Item Type,Publication Year,Author,Title,DOI,Change characteristics (blue),Ac
LB5MEY9S,journalArticle,2017,"Norskov, Sladjana; Kesting, Peter; Ulhoi, John Parm",Deliberate change without hierarchical influence? The case of collaborative OSS communities,10.1108/IJOA-08-2016-1050,,,,,
KUWLMFWM,journalArticle,2017,"Santos, Carlos Denner D60os",Changes in free and open source software licenses: managerial interventions and variations on project attractiveness,10.1186/s13174-017-0062-3,"procedural --- license changes. managerial interventions in the nature of the license selected for the project; loosening the license makes the project more attractive, restricting it makes it less attractive; but asymmetric impacts though, there are more specific gradations of usefulness when moving between licenses than listed above",contributors to OSS projects --- ostensibly maintainers who are able to write to the license and switch the listed license. the project uses the framing of “managers” of OSS projects but it’s entirely backwards and should be disregarded.,"environment of attractiveness, as defined through lookups, selections and stated intent to download. as parts of this, project user base, attractiveness through use and downloads make up the environment.",Quantitative --- mining OSS projects on source forge that have had interventions/changes to their license selection then comparing against download and popularity data,"Mapping org studeis brain uncritically onto FOSS projects leads to failures within the empirical study; Just not very good, really grandiose in its claims; not sure how they’re going to isolate managerial intervention within the structure of OSS projects which,… rather famously do not have managers"
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,,,,,
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,,,,,
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

1 Key Item Type Publication Year Author Title DOI Change characteristics (blue) Actors (purple) Environmental characteristics (green) Methods details (orange) Misc. (red)
2 LB5MEY9S journalArticle 2017 Norskov, Sladjana; Kesting, Peter; Ulhoi, John Parm Deliberate change without hierarchical influence? The case of collaborative OSS communities 10.1108/IJOA-08-2016-1050
3 KUWLMFWM journalArticle 2017 Santos, Carlos Denner D60os Changes in free and open source software licenses: managerial interventions and variations on project attractiveness 10.1186/s13174-017-0062-3 procedural --- license changes. managerial interventions in the nature of the license selected for the project; loosening the license makes the project more attractive, restricting it makes it less attractive; but asymmetric impacts though, there are more specific gradations of usefulness when moving between licenses than listed above contributors to OSS projects --- ostensibly maintainers who are able to write to the license and switch the listed license. the project uses the framing of “managers” of OSS projects but it’s entirely backwards and should be disregarded. environment of attractiveness, as defined through lookups, selections and stated intent to download. as parts of this, project user base, attractiveness through use and downloads make up the environment. Quantitative --- mining OSS projects on source forge that have had interventions/changes to their license selection then comparing against download and popularity data Mapping org studeis brain uncritically onto FOSS projects leads to failures within the empirical study; Just not very good, really grandiose in its claims; not sure how they’re going to isolate managerial intervention within the structure of OSS projects which,… rather famously do not have managers
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
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