diff --git a/070725_papers_master.csv b/070725_papers_master.csv
index 2067cda..b4d3cd2 100644
--- a/070725_papers_master.csv
+++ b/070725_papers_master.csv
@@ -19,7 +19,7 @@ FJSA37EW,journalArticle,2021,"Bogart, Chris; Kästner, Christian; Herbsleb, Jame
 72F8GVAP,journalArticle,2025,"Jahanshahi, Mahmoud; Reid, David; Mockus, Audris",Beyond Dependencies: The Role of Copy-Based Reuse in Open Source Software Development,10.1145/3715907,,,,,
 QEKG8ISF,journalArticle,2016,"Hilton, Michael; Tunnell, Timothy; Huang, Kai; Marinov, Darko; Dig, Danny","ASE - Usage, costs, and benefits of continuous integration in open-source projects",10.1145/2970276.2970358,"Procedural – adoption and change to CI systems within project builds --- though the rational for initial adoption are intrinsic to the project, the reasons for changing or evolving the CI yaml file are largely contingent on dependencies and reliability","OSS maintianers, specifically of popular projects on GitHub, many of whom have used CI workflows in their builds",OSS on GitHub --- no evaluation of whether CI changes ‘work’ for their environment though I guess adherence to the new dependency is the thing that would display that ,"mixed-methods: mining open source projects from GitHub while also surveying developers from  popular projects.survey sampling is NOT from the mined authorship data, instead focusing on popular GitHub projects",he discussion of adaptive change is often framed within the broader setting of whether or not the change is popular/relevant -- i.e. 40% of projects are using CI systems 
 ZGK4HR76,journalArticle,2015,"Vendome, Christopher; Linares-Vasquez, Mario; Bavota, Gabriele; Di Penta, Massimiliano; German, Daniel M.; Poshyvanyk, Denys",ICSME - When and why developers adopt and change software licenses,10.1109/icsm.2015.7332449,Procedural – license changes within OSS projects --- the change event is the real adaptation action; rationale for commercial reuse is also a motivating factor ,"OSS maintainers (Java, on GitHub) who change the license --- oftentimes this is a copyright holder or primary core contirbutor of the project ","nebulous environment of commercial reuse, ‘community’, and user base --- there’s also discussion around the role that changes to the broader dependency network play in the structure of the project and changes to the license",Mixed-methods; mining 16k java open source projects and their commits and then supplemented with survey study of 138 developers; sample of developers surveyed are from the trace data of the mined project actions --- specifically looking to identify projects that had shifted over time with regard to licensing,many of the intitial decisions and adaptations were motivated from a range of intrinsic and extrinsic motivations
-PSZSSAS3,journalArticle,2017,"Ding, Hui; Ma, Wanwangying; Chen, Lin; Zhou, Yuming; Xu, Baowen",APSEC - An Empirical Study on Downstream Workarounds for Cross-Project Bugs,10.1109/apsec.2017.38,,,,,
+PSZSSAS3,journalArticle,2017,"Ding, Hui; Ma, Wanwangying; Chen, Lin; Zhou, Yuming; Xu, Baowen",APSEC - An Empirical Study on Downstream Workarounds for Cross-Project Bugs,10.1109/apsec.2017.38,"Technical – downstream workarounds from errors and bugs and undesirable method behavior introduced by upstream dependencies -- common workaround per prior literature -- workarounds fall into four common patterns: using a different method, wrapping the current method in a conditional per input, augmenting input to match method, augmenting method output to match downstream ",OSS project developers of downstream scientific python libraries on GitHub ,Scientific python dependency ecosystem on GitHub,mixed-methods; though statistical methods were used in evaluating hypotheses or finding differences in the workarounds; manual methods were used for cross-project bugs with workarounds in the first place as well as some characterization of the bugs ,the short-term adaptations are meaningfully different than the long-term fixes across the environment  there’s a lot of similarity in the kinds of cross-project bugs that run into this problem/adaptation --- often when the downstream project encounters an emergent case that is untested by the upstream repository
 V3F8FYG5,journalArticle,2018,"Meloca, Rômulo; Pinto, Gustavo; Baiser, Leonardo; Mattos, Marco; Polato, Ivanilton; Wiese, Igor; German, Daniel M.","Understanding the usage, impact, and adoption of non-OSI approved licenses",10.1145/3196398.3196427,Organizational / procedural--  adoption of non OSI approved licenses or change to OSI-approved license --- the majority of the changes in either direction were from the adoption or deletion of a license (which happened to be OSI compliant) --- RQ3 provides naivete or lack of care for reasoning for moves into non-approved licenses,OSS package publishers --- some of whom have published packages with non-OSI approved licenses  ,"governing body --- OSI is an open source regulator, vets the software license to make sure that it’s either open source or not --Also looking at compliance within three well-known open source libraries: NPM, RubyGems and CRAN; these enviroments are kinda nested within the focal environment, compliance in terms of sync with dependencies --- check of ‘success’ or anything: majority of the time, surveyed developers are not checking whether the different licenses they select are conforming, or adhering to anything",Mixed-methods: mining packages from the three different package manager environments -- pulled down a bunch of package data from the different ecosystems and looked through their license change over specified versions: a survey with the publishers of the package. sampled from NPM. open responses were qualitatively coded by pairs of researchers ,not happy with the way that the different segments of the project are conflated with each other --- what use is the response of developers who use specific non-compliant licenses when the majority of non-compliance evolution is deletion or lack of license? --- different sets of populations between different methods sections of the research --- “developers might not fully understand the effect of the adaptive action that they’re taking” --- contributors ‘dont care; about the licenses they use
 6AQY86BW,journalArticle,2022,"Businge, John; Openja, Moses; Nadi, Sarah; Berger, Thorsten",Reuse and maintenance practices among divergent forks in three software ecosystems,10.1007/s10664-021-10078-2,,,,,
 YJREPLGY,journalArticle,2023,"Venturini, Daniel; Cogo, Filipe Roseiro; Polato, Ivanilton; Gerosa, Marco A.; Wiese, Igor Scaliante",I Depended on You and You Broke Me: An Empirical Study of Manifesting Breaking Changes in Client Packages,10.1145/3576037,,,,,
@@ -27,7 +27,7 @@ QIVH9LJG,journalArticle,2017,"Abdalkareem, Rabe; Nourry, Olivier; Wehaibi, ; Muj
 TFDYF5UM,journalArticle,2011,"Capiluppi, Andrea; Stol, Klaas-Jan; Boldyreff, Cornelia",Software Reuse in Open Source: A Case Study,10.4018/jossp.2011070102,,,,,
 XDY5INZ6,conferencePaper,2018,"Lotter, Adriaan; Licorish, Sherlock A.; Savarimuthu, Bastin Tony Roy; Meldrum, Sarah",Code Reuse in Stack Overflow and Popular Open Source Java Projects,10.1109/ASWEC.2018.00027,"technical -- code reuse from Stack Overflow within popular Java OSS projects--  rationale is copying from stackoverflow or other popular projects, which inherently increases technical fit with the environment --- disregarding within project copying, that is almost a meaningless metric  copying between projects is larger (in size of code segment that’s copied over) and may be more prevalent?",OSS project developers for popular/well-regarded projects -- I guess this action is also at the developer/contributor level.,"The most popular Java OSS projects on SourceForge and GitHub --- in 2017, which projects had the highest weekly popularity and contained requisite Java code or, alternatively, the projects that had the highest popularity on SourceForge; Also looking at all Java StackOverflow comments from 2014-2017. pulling out the code snippets from these answers","quantitative repo mining from Stack Overflow and most popular Java projects --- focusing on weekly and all-time popularity for GitHub and SourceForge metrics --- used near-OTS code reuse identification software changing parameters for a few things ; reliant on syntax and token similarity, not AST for analysis","paper finger wags about code reuse the whole time, discussing how it’s not a good practice. Adaptive change can lead to adherence to substandard environmental norms. Seems like code reuse from Stack Overflow isn’t even that prevalent? Not a very good paper honestly; never discusses when the code was reused within or in which direction --- it’s cross sectional data!! How can you even make an argument surrounding copying, which is a time-dependent action!"
 MBVCDT66,journalArticle,2023,"He, Runzhi; He, Hao; Zhang, Yuxia; Zhou, Minghui",Automating Dependency Updates in Practice: An Exploratory Study on GitHub Dependabot,10.1109/TSE.2023.3278129,"organizational/procedural -- adoption of dependabot--- stated rationale: managing project dependencies --- specifically, keeping project dependencies up to date ---","OSS developers for projects that have adopted dependabot --- specifically, developers who are likely to be familiar with dependabot and its workings","GitHub ---- specifically the projects on GitHub but often, the platform itself structures the environment that projects operate in --- also dependency networks, the reasoning why dependabot is used is for projects to align better with the dependencies that they’re reliant on","mixed-methods, EDA and a developer survey --- from a sample of 1823 projects, mining the PRs made by Dependabot with a survey of the projects’ developers (n131)--- sampled for the survey from the projects that were identified in the mining scenario -- a lot of researcher selection in finding maintainers who are likely to be familiar with it","a lot of analysis on whether or not adopting dependabot works, like whether the thing that people are doing to adapt is… actually working… even though dependabot is not that useful for automatic updates, many developers believe that it is useful for notifying updates"
-DGV2UJNM,conferencePaper,2020,"Zhou, Shurui; Vasilescu, Bogdan; Kästner, Christian",How has forking changed in the last 20 years? a study of hard forks on GitHub,10.1145/3377811.3380412,,,,,
+DGV2UJNM,conferencePaper,2020,"Zhou, Shurui; Vasilescu, Bogdan; Kästner, Christian",How has forking changed in the last 20 years? a study of hard forks on GitHub,10.1145/3377811.3380412,"technical and procedural --- the changing of a fork from social to hard in GitHub;the forks often start social, but then move to hard once obstacles to contributing upstream were found, whether that be unresponsive maintainers or rejected pull requests","GitHub repo owners of hard-forked OSS projects are the ones who effect the adaptive change ; though the quantitative sample looks at 15,306 hard forks on GitHub (initiated/shepherded by the owners of those hard forks), the interview sample looks at 15 owners of forked libraries --- these are long-tenured OSS contributors ","forking networks on GitHub, the environmental characteristics are unresponsive upstream projects or barriers to contributing to the upstream project; the hard fork is downstream of the construction of the upstream project as external to the social fork","mixed-methods; mining and classifying hard-forked projects and then interviewing the owners of those repositories/maintainers of upstream; heuristic classifier to find hard forks, qualitative card sorting to characterize them; qualitative interviews to gain perspective -- interview sample created from identifying hard forked projects and authors ","hard forks are, generally, a rare phenomenon across GitHub -- though the scale of GitHub means that the total number of these forks is actually pretty large; another verification of respondent claims: “we see little evidence of actual synchronization or merging across forks in the repositories:” ([Zhou et al., 2020, p. 453"
 QLSEMWTQ,journalArticle,2017,"Vendome, Christopher; Bavota, Gabriele; Penta, Massimiliano Di; Linares-Vásquez, Mario; German, Daniel; Poshyvanyk, Denys",License usage and changes: a large-scale study on gitHub,10.1007/s10664-016-9438-4,,,,,
 5E2EWRQN,journalArticle,2020,"Abdalkareem, Rabe; Oda, Vinicius; Mujahid, Suhaib; Shihab, Emad",On the impact of using trivial packages: an empirical case study on npm and PyPI,10.1007/s10664-019-09792-9,technical: code reuse: trivial package reuse: rationale – trivial packages provide well-implemented and tested code from the packaging ecosystem: enables adherence to the quality testing of the broader ecosystem,application developers: long-tenured JS and Python coders: largely professional but some independents,package managemeny systems: npm and PyPI: change adheres project to well-tested and implemented environment: no project evaluation of change ‘success’ wrt environment ,mixed methods: pilot survey – data mining – follow up survey – data mining to validate survey responses: sampling from prior methods step: skews to university ,internal motivations for productiivty: many also stated that reuse was bad: paper spends a lot of time defining trivial packages
 P3MTJWXP,conferencePaper,2022,"Zhang, Xunhui; Wang, Tao; Yu, Yue; Zeng, Qiubing; Li, Zhixing; Wang, Huaimin","Who, What, Why and How? Towards the Monetary Incentive in Crowd Collaboration: A Case Study of Github’s Sponsor Mechanism",10.1145/3491102.3501822,procedural/organizational: developer adoption and participation in the GitHub sponsors program --- rationale for adopting the sponsorship model: I should be rewarded or recognized for my OSS work ,"OSS developers, but not necessarily those with big commits or key contributions, the popular ones who work on big projects","GitHub --- and also broader society. the adoption of the feature is bound to the platform as the environment --- as such, the bounds of the project’s activity are restricted by GitHub as a platform --- to what extent is broader social environment (intrinsic desire for payment) also the environment here?",mixed-methods -- both data mining and survey; quantitative data mining of different sponsorship events within GitHub --- pulling a lot of data on the individual sponsorships and the sponsoring events --- statistic modeling (lmer) of maintainer/contributor balance etc.; Sampling from the data mining to identify the relevant population.; qualitative already with a questionnaire about the why and what questions.  -- survey looked up the expectations and rationales for using the sponsor feature ; two-stage survey,"again a validity check of the contributor rationales --- How effective is the sponsorship mechanism with carving out time for maintainers to work on things --- didn’t hold up!; configurable adaptations more throughout this, not the first paper that discusses this; environment (GitHub) is incredibly deterministic in establishing who adapts/adopts the feature --- instead of being an amorphous social pressure or anything like that --- it is a platform trying to get you to use their most recent feature; intersection of rationales for doing things sit at the intersection of intrinsic and extrinsic motivations"