32/34

070725_papers_master.csv

@@ -1,5 +1,5 @@
 Key,Item Type,Publication Year,Author,Title,DOI,Change characteristics (blue),Actors (purple),Environmental characteristics (green),Methods details (orange),Misc. (red)
-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,,,,,
+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,"Procedural --- focal change is the organizational prioritization of usability. Change agent within the project identified usability as a critical deficiency of the project, installing usability as a mindset; external; redirecting the project’s focus towards usability, mitigating the extreme focus on technicality. initially proposed by a newcomer to the project, who became the change agent for the project, and made the explicit decision to launch a process of change for the project. the adaptation remained inthe background for 5 years; delayed implementation of the adaptive change--- proposed in 2001 and then not adopted until 2006.  -     change agent needed to wade through a wide range of bureaucracy and muddled-ness in order to advocate for the change and get it implemented      - a lot of the hierarchy and burarucracy continues within things","specific contributors to the TYPO3 project who are not necessarily high in the hierarchy when the strategic change begins… there is some accumulation of social capital and status that is developed through the act of whipping for a given change  gaining legitimacy from the project founder and other developers higher up in the project; this requires strategic action by both the change agent and the higher ups in hte project, the higher ups redirect attention back towards the change agent and build up his status within the OSS project  the construction of the change agent is two-sided, from the individual as well as from the surrounding hierarchy","project user space of TYPO3; some of the other changes were made for internal reasons surrounding productivity or transparency---- but two others were made for the sake of product usability for users; the usability question ---> the project was directly compared to WordPress and Drupal in the discussions around usability, prompting a direct comparison with environmental competitors","qualitative --- longitudinal qualitative case study of TYPO3; four years of project development from 2006-2010. focusing on one strategic change initiative carried out to try to redirect the project’s focus towards product usability and user satisfaction; nonrandom sampling for the case study to look at representative example and a mature case; TYPO3: public CMS with small group of developers working on R&D. Now a more mature project with larger user base working on similar stuff (registered developer boom from 2003-2005 was the reason for studying the project); data sources: interviews, observations of meetings, community mailing lists, and archival data; most of the interviews were with the core members/higher up on the hierarchy of the system; might be a sampling bias towards the higher up structure of things; qualitative analysis of the data --- looking at the emergence of organizational practices within the grounded setting of the data; used grounded theory analysis methods to identify different concepts and relationships within the data; four categories to use to analyze the mechanisms employed to address deliberate change","deliberate change as the object of study in and of itself; trying to generalize their single case study with the development of a model?; using/parrotting the core/peripheral model of OSS development, meritocracy argument, and motivations things; argument that leadership power is necessary for overcoming the friction of deliberate change; most of the interviews were with the core members/higher up on the hierarchy of the system; might be a sampling bias towards the higher up structure of things"
 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,"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"