CoChat
Sign Up
Cited by 2Open Source Software InnovationsSoftware Engineering Techniques and PracticesSoftware Engineering Research

Governance in Practice: How Open Source Projects Define and Document Roles

Open access
Oliveira, Pedro, Conte, Tayana, Gerosa, Marco, Steinmacher, Igor·2026·Proceedings of the 19th International Conference on Cooperative and Human Aspects of Software Engineering
DOI 10.1145/3794860.3794911
Open this paper in CoChat — free account

Abstract

Open source software (OSS) sustainability depends not only on code contributions but also on governance structures that define who decides, who acts, and how responsibility is distributed. We lack systematic empirical evidence of how projects formally codify roles and authority in written artifacts. This paper investigates how OSS projects define and structure governance through their GOVERNANCE.md files and related documents. We analyze governance as an institutional infrastructure, a set of explicit rules that shape participation, decision rights, and community memory. We used Institutional Grammar to extract and formalize role definitions from repositories hosted on GitHub. We decompose each role into scope, privileges, obligations, and life-cycle rules to compare role structures across communities. Our results show that although OSS projects use a stable set of titles, identical titles carry different responsibilities, and different labels describe similar functions, which we call role drift. Still, we observed that a few actors sometimes accumulate technical, managerial, and community duties. By understanding authority and responsibilities in OSS, our findings inform researchers and practitioners on the importance of designing clearer roles, distributing work, and reducing leadership overload to support healthier and more sustainable communities.

Verified 2026-11-02 · 30 references not checked yet

AI snapshot

Written from the paper’s full text.

TL;DR

This paper analyzes written governance artifacts from GitHub OSS projects to characterize how roles, responsibilities, privileges, and promotion/demotion rules are documented. It finds stable role titles but substantial “role drift,” with identical titles carrying different duties and composite roles—especially maintainers—concentrating technical, managerial, and community authority.

Key findings

  • Across 8,000 license-stratified GitHub repositories, only 72 (0.90%) had a governance file detected, and 54 (0.67%) had governance files with content.
  • Organizational Structure appeared in 54/54 governance documents (100%), followed by Decision Making in 53 (98%), Core Processes in 49 (90%), Community and Communication in 43 (80%), Project Context in 32 (59%), and Compensation Schemes in 7 (13%).
  • Manual clustering identified 133 role instances: Core Maintainer (50), Contributor (29), Steering (20), User (12), Project Specific (9), Owner (8), Advocacy (4), Emeritus Maintainer (4), Triage (3), Reviewer (2), and Committer (1).
  • The paper describes “role drift”: the same title often carries different responsibilities, while different labels describe similar functions; maintainers are the most composite role, producing what the authors call the “Maintainer Paradox,” where governance centralizes power in those meant to distribute it.

Methods

  • Qualitative analysis of governance files from GitHub repositories. Projects were public, had an explicit open-source license, and were ranked by stargazer count within license strata; the authors retrieved 1,000 repositories per license category and searched recursively for files whose names contained “governance.”
  • Two-stage qualitative coding of governance topics followed Saldaña’s iterative coding guidelines, yielding six high-level topics. Role extraction used a template grounded in Institutional Grammar: scope of responsibility, responsibilities, privileges, and promotion/demotion criteria; fields were marked “absent” when not explicitly stated.
  • Extracted roles were mapped to an adapted open-source skills catalog from Liang et al. using a 45-dimensional binary skill matrix. Unsupervised clustering (K-Means, Agglomerative Clustering, DBSCAN) was unstable, so the authors pivoted to manual interpretive clustering by three authors, with consensus-based assignment to clusters such as Contributor, Core Maintainer, Steering/Leadership, Reviewer, Triage, User, and Project-Specific Roles.

Limitations

  • The paper states that ranking by GitHub stars may over-represent socially prominent projects, so findings characterize highly visible communities that codify governance rather than all OSS projects.
  • The paper states that detecting governance files only by names containing “governance” likely excluded projects that govern informally or host rules outside the repository, and that restricting extraction to explicit statements means results describe governance as written, not necessarily as enacted.
  • The paper also states that the Institutional Grammar schema may fragment holistic responsibilities or understate hybrid roles, and that manual interpretive clustering increased interpretive judgment; the authors deliberately avoid linking governance forms to outcomes such as retention or success. Evident from Table 1, the final sample of 54 governance files with content is small and skewed toward Apache-2.0 (30 files), limiting generalizability.

Model-written summary. Check it against the paper before relying on it.

Integrity signals

Registry

Crossref · 10.1145/3794860.3794911

Cites

29 of 59 references verified0 citation errors · 0 not checkable

Statistics

Nothing to recompute.

Claims the paper makes

21 of 65 cited sources checked · 4 supported · 1 flagged · accuracy not yet measured

  • Premisecitation
    § 2 Related Work · p. 2

    As OSS projects grow in scale and complexity, informal governance arrangements often become insufficient for ensuring accountability, transparency, and continuity.

    “As OSS projects grow in scale and complexity, empirical studies indicate that informal governance arrangements often become insufficient for ensuring accountability, transparency, and continuity [24, 56].”
    Quote in the paperSubstantial claim2 of 2 sources checked
    • cites [24] [24] Chris Jensen and Walt Scacchi. 2010. Governance in open source software development projects: A comparative multi-level analysis. In IFIP International Conference on Open Source Systems . Springer Berlin Heidelberg, Berlin, Heidelberg, 130-142. - source

      Section 2 (page unavailable) says OSS participants can often suffice with lightweight governance forms adapted to their needs. The Conclusions (page unavailable) present self-governance as an alternative to the view that complex, reliable software requires explicit central management. The paper notes partially assigned accountability in NetBeans, but does not conclude that growing scale makes informal governance insufficient for accountability, transparency, or continuity. (LLM, conf=0.82)

      Checked by a reasoning model — may be wrong.

      Experimental — accuracy not yet measured
    • cites [56] [56] Likang Yin, Mahasweta Chakraborti, Yibo Yan, Charles Schweik, Seth Frey, and Vladimir Filkov. 2022. Open source software sustainability: Combining institutional analysis and socio-technical networks. Proceedings of the ACM on HumanComputer Interaction 6, CSCW2 (2022), 1-23. - source

      Section 2.3 says governance must adapt as an organization’s context changes, and the Discussion reports an association between more active institutional governance and OSS project graduation. The paper does not establish that growth in scale or complexity makes informal governance insufficient, or that this insufficiency threatens accountability, transparency, and continuity. (LLM, conf=0.83)

      Experimental — accuracy not yet measured
  • Premisecitation
    § 2.1 Roles, Pathways, and Belonging in OSS · p. 2

    Contributors' trajectories are shaped not only by technical expertise but also by social and communicative engagement.

    “These trajectories are shaped not only by technical expertise, but also by social and communicative engagement, as contributors' progress depends on their ability to build relationships, exchange feedback, and gain recognition within the community [3, 49, 53, 58].”
    Quote in the paperNot a substantial claim3 of 4 sources checked
    • cites [3] [3] Ann Barcomb, Andreas Kaufmann, Dirk Riehle, Klaas-Jan Stol, and Brian Fitzgerald. 2018. Uncovering the periphery: A qualitative survey of episodic volunteering in free/libre and open source software communities. IEEE Transactions on Software Engineering 46, 9 (2018), 962-980. - source

      Section 6.1 (Contributor Motivation; page not provided) links technical barriers and opportunities for interaction and relationship-building to whether episodic volunteers join or remain. Section 6.4 (Satisfaction; page not provided) discusses appreciation and recognition. The paper does not establish that contributors’ progress depends on exchanging feedback or gaining recognition, so the broader claim about trajectories goes beyond its findings. (LLM, conf=0.84)

      Experimental — accuracy not yet measured
    • cites [49] [49] Igor Steinmacher, Marco Aurélio Gerosa, and David Redmiles. 2014. Attracting, onboarding, and retaining newcomer developers in open source software projects. In Workshop on Global Software Development in a CSCW Perspective , Vol. 16. Association for Computing Machinery, New York, NY, USA, 20. -

      Not checked in the free run.

    • cites [53] [53] Bianca Trinkenreich, Mariam Guizani, Igor Wiese, Anita Sarma, and Igor Steinmacher. 2020. Hidden figures: Roles and pathways of successful OSS contributors. Proceedings of the ACM on human-computer interaction 4, CSCW2 (2020), 1-22. - source

      The Conclusion reports that contributors’ career paths include community-centric roles, even for people with technical expertise, and the OSS Advocate section describes connecting people and recognizing talent. This supports the claim that trajectories involve more than technical expertise. The paper does not establish the citing sentence’s more specific assertion that contributors’ progress depends on exchanging feedback. (LLM, conf=0.83)

      Experimental — accuracy not yet measured
    • cites [58] [58] Minghui Zhou and Audris Mockus. 2014. Who will stay in the floss community? modeling participant's initial behavior. IEEE Transactions on Software Engineering 41, 1 (2014), 82-99. source
  • Premisecitation
    § 1 Introduction · p. 1

    Several OSS projects still rely on informal or opaque governance practices, often centered on a few long-standing maintainers.

    “Several OSS projects still rely on informal or opaque governance practices, often centered on a few long-standing maintainers [22, 29, 39].”
    Quote in the paperSubstantial claim2 of 3 sources checked
    • cites [22] [22] Mariam Guizani, Amreeta Chatterjee, Bianca Trinkenreich, Mary Evelyn May, Geraldine J Noa-Guevara, Liam James Russell, Griselda G Cuevas Zambrano, Daniel Izquierdo-Cortazar, Igor Steinmacher, Marco A Gerosa, et al. 2021. The long road ahead: Ongoing challenges in contributing to large OSS organizations and what to do. Proceedings of the ACM on Human-Computer Interaction 5, CSCW2 (2021), 1-30. - source

      Section 5.1 reports unclear voting and consensus rules, and the Discussion describes vague regulations and calls for clearer guidance on the ASF’s governance structure. Section 7.1 reports a participant’s view that people with less than ten years’ experience are not well regarded as foundation leaders. These passages support concerns about opaque governance and the influence of tenure, but do not establish that several OSS projects rely on informal governance centered on a few long-standing maintainers. (LLM, conf=0.82)

      Experimental — accuracy not yet measured
    • cites [29] [29] Johan Linåker, Georg Link, and Kevin Lumbard. 2024. Sustaining maintenance labor for healthy open source software projects through human infrastructure: - source

      The Introduction (section 1; page unavailable) says that a small core of maintainers performs much of the maintenance labor in many OSS projects and that maintainers undertake project governance. It does not establish that those maintainers are long-standing or that the governance practices are informal or opaque. (LLM, conf=0.85)

      Experimental — accuracy not yet measured
    • cites [39] [39] Naveen Raman, Minxuan Cao, Yulia Tsvetkov, Christian Kästner, and Bogdan Vasilescu. 2020. Stress and burnout in open source: Toward finding, understanding, and mitigating unhealthy interactions. In Proceedings of the ACM/IEEE 42nd International Conference on Software Engineering: New Ideas and Emerging Results . Association for Computing Machinery, New York, NY, USA, 57-60. - source
  • Premisecitation
    § 2 Related Work · p. 2

    Early governance models, such as benevolent dictator or consensus-based meritocracies, depended on informal social contracts, technical reputation, and sustained contribution instead of codified policy.

    “Early governance models, such as the benevolent dictator paradigm or consensus-based meritocracies, depended on informal social contracts, technical reputation, and sustained contribution instead of codified policy [4, 30, 42].”
    Quote in the paperNot a substantial claim1 of 3 sources checked
    • cites [4] [4] Mirko Boehm. 2019. The emergence of governance norms in volunteer-driven open source communities. IFOSS L. Rev. 11 (2019), 3. -

      Not checked in the free run.

    • cites [30] [30] Johan Linåker, Björn Regnell, and Daniela Damian. 2019. A Community Strategy Framework-Howtoobtain influence on requirements in meritocratic open source software communities? Information and Software Technology 112 (2019), 102-114. - source

      Section 2.2 (pp. 4–6) describes dictator-based and meritocratic governance and says authority in meritocracies is earned through trust, status, and contributions. Section 6.2 (p. 24) also describes earning trust and respect in dictator-based communities. The paper does not establish that these were early models governed by informal social contracts instead of codified policy, and it cautions that merit is not limited to technical contributions. (LLM, conf=0.85)

      Experimental — accuracy not yet measured
    • cites [42] [42] Dalia Ritvo, Kira Hessekiel, and Christopher Bavitz. 2017. Challenges & opportunities concerning corporate formation, nonprofit status, & governance for open source projects. Berkman Klein Center Research Publication 3 (2017), 17-31. - source
  • Premisecitation
    § 2.1 Roles, Pathways, and Belonging in OSS · p. 2

    Contributors rarely assume authority immediately; they progress from peripheral participation to more central involvement through learning, recognition, and sustained interaction.

    “Contributors rarely assume authority immediately. They progress from peripheral participation to more central forms of involvement through a combination of learning, recognition, and sustained interaction [48, 53, 58].”
    Quote in the paperNot a substantial claim2 of 3 sources checked
    • cites [48] [48] Yunlong Song. 2021. Role Classification and Transition of OSS Developers . Master's thesis. University of California, Irvine. -

      Not checked in the free run.

    • cites [53] [53] Bianca Trinkenreich, Mariam Guizani, Igor Wiese, Anita Sarma, and Igor Steinmacher. 2020. Hidden figures: Roles and pathways of successful OSS contributors. Proceedings of the ACM on human-computer interaction 4, CSCW2 (2020), 1-22. - source

      The ‘Legitimate Peripheral Participation’ section reports that 12 participants lurked before learning enough to participate, supporting the claim that contributors often do not begin in central roles. But ‘What about the Onion Model?’ says only two of 17 followed the typical progression to the core, and the paper describes some contributors who began in central positions. Recognition appears in the Related Work discussion, but the paper does not establish sustained interaction as part of a general progression. (LLM, conf=0.86)

      Experimental — accuracy not yet measured
    • cites [58] [58] Minghui Zhou and Audris Mockus. 2014. Who will stay in the floss community? modeling participant's initial behavior. IEEE Transactions on Software Engineering 41, 1 (2014), 82-99. source

      The Introduction describes newcomers learning project norms and experienced contributors building rapport and taking on more important tasks. Section 4.1 describes learning through interaction with established members and small tasks, while Section 4.2.2 discusses attention from peers. The paper does not establish that contributors generally progress from peripheral participation to central involvement or gain authority through that particular combination of factors. (LLM, conf=0.84)

      Experimental — accuracy not yet measured
  • Classified as probably not a substantial claim. 40
  • May combine two claims. 40
  • The quote only partly states this claim. 2

  • Probably not a substantial claim: may not pass S3 (load-bearing).

    Premisecitation
    § 2 Related Work · p. 2

    OSS governance becomes institutionalized as communities formalize norms and practices into explicit structures like charters and artifacts to manage coordination challenges and sustain development.

    “This leads to the institutionalization of OSS governance, where communities formalize norms and practices into explicit structures like charters, and artifacts to manage coordination challenges and sustain development [7, 11, 15].”
    Quote in the paperNot a substantial claim1 of 3 sources checked
    • cites [7] [7] Mahasweta Chakraborti, Curtis Atkisson, Ştefan Stănciulescu, Vladimir Filkov, and Seth Frey. 2024. Do We Run How We Say We Run? Formalization and Practice of Governance in OSS Communities. In Proceedings of the 2024 CHI Conference on Human Factors in Computing Systems (Honolulu, HI, USA) (CHI '24) . Association for Computing Machinery, New York, NY, USA, Article 923, 26 pages. doi:10.1145/3613904.3641980 - source

      The Introduction (p. 1) says written policies help coordinate OSS communities and that informal norms help sustain development; the Discussion (p. 14) describes foundations establishing formal policies and hierarchies. But the paper does not establish that formalizing norms into charters and artifacts sustains development: its Conclusion (p. 17) says governance around highly formalized concerns has little bearing on success or sustainability. A charter appears in an appendix list of graduation procedures, not as evidence for the claimed process. (LLM, conf=0.86)

      Experimental — accuracy not yet measured
    • cites [11] [11] Benoit Demil and Xavier Lecocq. 2006. Neither market nor hierarchy nor network: The emergence of bazaar governance. Organization studies 27, 10 (2006), 14471466. - source
    • cites [15] [15] Nadia Eghbal. 2016. Roads and Bridges: The Unseen Labor Behind Our Digital Infrastructure. https://www.fordfoundation.org/learning/library/researchreports/roads-and-bri dges-the-unseen-labor-behind-our-digital-infrastructure/. -

      Not checked in the free run.

  • May combine two claims.

    Premisecitation
    § 1 Introduction · p. 1

    Prior work focusing on individual projects, such as the data.table case study, provides valuable qualitative insights into consequences of restructuring projects through governance models but lacks a cross-project perspective.

    “Prior work focusing on individual projects, such as the case study of the data.table community [34], provides valuable qualitative insights into the consequences of restructuring projects through governance models, but lacks a crossproject perspective that captures the diversity of governance structures across the OSS landscape.”
    Quote in the paperSubstantial claim1 of 1 sources checked
    • cites [34] [34] Pedro Oliveira, Doris Amoakohene, Toby Hocking, Marco Gerosa, and Igor Steinmacher. 2025. Governance Matters: Lessons from Restructuring the data. table OSS Project. In 2025 IEEE International Conference on Software Maintenance and Evolution (ICSME) . IEEE, Piscataway, NJ, USA, 1-12. - source

  • Probably not a substantial claim: may not pass S3 (load-bearing).

    Premisecitation
    § 2.2 The (Lack of) Documented Governance · p. 2

    Oliveira et al. showed how rewriting a project's governance file reshaped decision-making patterns and community health in the data.table ecosystem.

    “Oliveira et al. [34] showed how rewriting a project's governance file reshaped decision-making patterns and community health in the data.table ecosystem.”
    Quote in the paperNot a substantial claim1 of 1 sources checked
    • cites [34] [34] Pedro Oliveira, Doris Amoakohene, Toby Hocking, Marco Gerosa, and Igor Steinmacher. 2025. Governance Matters: Lessons from Restructuring the data. table OSS Project. In 2025 IEEE International Conference on Software Maintenance and Evolution (ICSME) . IEEE, Piscataway, NJ, USA, 1-12. - source

      The Governance Reform Process section describes a repository governance specification that formalized roles and decision-making procedures. The Transparency and Decision-Making Clarity section reports improved perceptions of decision-making, and the Conclusions report gains in contributor retention and responsiveness. But the paper evaluates a broader governance reform, not the effect of rewriting the file alone; it also notes concurrent community-building efforts and does not establish a change in actual decision-making patterns. Page numbers are unavailable in our copy. (LLM, conf=0.84)

      Experimental — accuracy not yet measured

  • May combine two claims.

    Premisecitation
    § 2.2 The (Lack of) Documented Governance · p. 2

    Existing work has mostly characterized how contributors gain authority or how leadership structures evolve, but has rarely investigated the governance artifacts that define these arrangements.

    “Existing work has mostly characterized how contributors gain authority or how leadership structures evolve, but has rarely investigated the governance artifacts that define these arrangements [24, 36].”
    Quote in the paperSubstantial claim1 of 2 sources checked
    • cites [24] [24] Chris Jensen and Walt Scacchi. 2010. Governance in open source software development projects: A comparative multi-level analysis. In IFIP International Conference on Open Source Systems . Springer Berlin Heidelberg, Berlin, Heidelberg, 130-142. - source

      Section 2 describes research on recruitment and role migration, and Section 4 examines leadership and control, supporting this paper as an example of work on those topics. But Sections 2–3 also describe the paper's analysis of project artifacts as governance mechanisms. The paper does not establish the broader claim that existing work has rarely investigated governance artifacts. (LLM, conf=0.79)

      Experimental — accuracy not yet measured
    • cites [36] [36] Siobhán O'mahony and Fabrizio Ferraro. 2007. The emergence of governance in an open source community. Academy of Management Journal 50, 5 (2007), 1079-1106. - source

  • Classified as probably not a substantial claim.

    Findingcitation
    § 3.4 Extracting Role Information · p. 4

    The output of the extraction step was a role-centric dataset where each entry represents a single role instance described in a governance document.

    “The output of this step, available in the replication package [35], was a role-centric dataset, where each entry represents a single role instance described in a governance document.”
    Quote in the paperSubstantial claim0 of 1 sources checked
    • cites [35] [35] Pedro Oliveira, Tayana Conte, Marco Gerosa, and Igor Steinmacher. 2025. Governance in Practice: How Open Source Projects Define and Document Roles. Zenodo. doi:10.5281/zenodo.17430401 Dataset, mining and analysis scripts. - source
    • Rests on an assumption: Written governance files provide an explicit and reliable record of how OSS projects define roles and distribute authority.

  • May combine two claims.

    Findingcitation
    § 4.2 What's in a Role? Skills Tell the Story · p. 7

    In vitessio/vitess, maintainers are entrusted with ongoing development and strategic alignment while remaining accountable through peer review and voting procedures.

    “In vitessio/vitess [55], maintainers are entrusted with ongoing development and strategic alignment while remaining accountable through peer review and voting procedures.”
    Quote in the paperNot a substantial claim0 of 1 sources checked
    • cites [55] [55] vitessio/vitess GitHub Project. 2025. Vitess. https://github.com/vitessio/vitess. Accessed: 22 October 2025. -

      Not checked in the free run.

  • May combine two claims.

    Findingcitation
    § 4.2 What's in a Role? Skills Tell the Story · p. 8

    In distribution/distribution, reviewers' votes are required to merge changes, making them guardians of project quality.

    “The distribution/distribution [12] reviewers' votes are required to merge changes, making them guardians of project quality.”
    Quote in the paperNot a substantial claim0 of 1 sources checked
    • cites [12] [12] distribution/distribution GitHub Project. 2025. Distribution. https://github.com/ distribution/distribution. Accessed: 22 October 2025. -

      Not checked in the free run.

  • May combine two claims.

    Findingcitation
    § 4.2 What's in a Role? Skills Tell the Story · p. 7

    In vitessio/vitess, contributors write code and documentation, support new users, and spread the project through talks or advocacy.

    “the vitessio/vitess governance file [55] captures this duality: contributors write code and documentation, are tasked with supporting new users and spreading the project through talks or advocacy.”
    Quote in the paperNot a substantial claim0 of 1 sources checked
    • cites [55] [55] vitessio/vitess GitHub Project. 2025. Vitess. https://github.com/vitessio/vitess. Accessed: 22 October 2025. -

      Not checked in the free run.

  • May combine two claims.

    Findingown data
    § 5.2 The Drift Between Codification and Practice · p. 9

    The same role title can denote very different responsibilities, while distinct titles often encode nearly identical duties.

    “The same role title can denote very different responsibilities, while distinct titles often encode nearly identical duties.”
    Quote in the paperSubstantial claim

  • Probably not a substantial claim: may not pass S3 (load-bearing).

    Findingown data
    § 3.3 Extracting Governance Topics · p. 4

    Project Context was documented in 32 governance files (59%).

    “| Project Context | 32 | (59%) |”
    Quote in the paperNot a substantial claim
    • Rests on an assumption: Written governance files provide an explicit and reliable record of how OSS projects define roles and distribute authority.
    • Rests on an assumption: The sampled GitHub repositories with governance files are representative of OSS projects more broadly.

  • May combine two claims.

    Findingown data
    § 3.5 Mapping Titles to Talents · p. 5

    Unsupervised clustering of the 45-dimensional binary skill matrix showed high sensitivity to parameter choices and low stability across thresholds.

    “However, the results showed high sensitivity to parameter choices and low stability across thresholds.”
    Quote in the paperNot a substantial claim
    • Rests on an assumption: Written governance files provide an explicit and reliable record of how OSS projects define roles and distribute authority.

  • The quote only partly states this claim.

    Findingown data
    § 5.3 Governance as Layered System · p. 9

    Governance in OSS projects tends to organize roles/responsibilities into two broad layers: organizational and operational.

    “Our results show that governance in OSS projects tends to organize responsibilities into two broad layers.”
    Quote in the paperSubstantial claim

  • May combine two claims.

    Findingreasoning
    § 4.2 What's in a Role? Skills Tell the Story · p. 7

    Contributors may produce artifacts or engage socially through communication (IS2) and collaboration (IS6), often involving one or more of these activities rather than all of them.

    “This mix underscores that contributors may produce artifacts or engage socially through communication (IS2) and collaboration (IS6), often involving one or more of these activities rather than all of them.”
    Quote in the paperNot a substantial claim

  • Probably not a substantial claim: may not pass S3 (load-bearing). May combine two claims.

    Findingcitation
    § 4.2 What's in a Role? Skills Tell the Story · p. 9

    In bpftrace/bpftrace, users require no qualifications, but their presence justifies the entire endeavor.

    “The bpftrace/bpftrace [6] project captures this ethos: users require no qualifications, but their presence justifies the entire endeavor.”
    Quote in the paperNot a substantial claim0 of 1 sources checked
    • cites [6] [6] Bpftrace/bpftrace GitHub Project. 2025. Bpftrace. https://github.com/bpftrace/ bpftrace. Accessed: 22 October 2025. -

      Not checked in the free run.

  • May combine two claims.

    Findingnone given
    § 4.2 What's in a Role? Skills Tell the Story · p. 7

    Committers have direct access to project resources and can make changes without submitting patches.

    “Their function is crucial, as they have direct access to the project's resources and can make changes without submitting patches.”
    Quote in the paperNot a substantial claim

  • May combine two claims.

    Findingreasoning
    § 4.2 What's in a Role? Skills Tell the Story · p. 7

    Maintainers' profiles span programming (T1), software engineering (T2), version control systems (T6), documentation (CT4), management skills (M1, M2, M3), and interpersonal abilities like communication (IS2) and collaboration (IS6).

    “Maintainers' profiles span across programming (T1), software engineering (T2), version control systems (T6), and documentation (CT4), while also emphasizing on management skills (M1, M2, M3) and interpersonal abilities like communication (IS2) and collaboration (IS6).”
    Quote in the paperSubstantial claim

  • May combine two claims.

    Findingown data
    § 3.5 Mapping Titles to Talents · p. 5

    At smaller distance cutoffs, agglomerative clustering produced many micro-clusters, while higher thresholds merged roles into broad, uninformative categories.

    “At smaller distance cutoffs, agglomerative clustering produced many micro-clusters, while higher thresholds merged roles into broad, uninformative categories.”
    Quote in the paperNot a substantial claim
    • Rests on an assumption: Written governance files provide an explicit and reliable record of how OSS projects define roles and distribute authority.

  • May combine two claims.

    Findingown data
    § 4.2 What's in a Role? Skills Tell the Story · p. 7

    Contributors are commonly associated with programming (T1), bug reporting (CT2), code review (CT3), and documentation (CT4).

    “As shown in the graphs, contributors are commonly associated with programming (T1), bug reporting (CT2), code review (CT3), and documentation (CT4).”
    Quote in the paperNot a substantial claim

  • Probably not a substantial claim: may not pass S3 (load-bearing). May combine two claims.

    Findingnone given
    § 4.2 What's in a Role? Skills Tell the Story · p. 7

    No role is more central or composite than core maintainer.

    “No role is more central, or more composite, than core maintainer.”
    Quote in the paperNot a substantial claim

  • Probably not a substantial claim: may not pass S3 (load-bearing).

    Findingown data
    § 3.3 Extracting Governance Topics · p. 4

    Compensation Schemes was documented in 7 governance files (13%).

    “| Compensation Schemes | 7 | (13%) |”
    Quote in the paperNot a substantial claim
    • Rests on an assumption: Written governance files provide an explicit and reliable record of how OSS projects define roles and distribute authority.
    • Rests on an assumption: The sampled GitHub repositories with governance files are representative of OSS projects more broadly.

  • Probably not a substantial claim: may not pass S3 (load-bearing).

    Findingcitation
    § 4.2 What's in a Role? Skills Tell the Story · p. 7

    In grafana/tempo, maintainers are defined as both technical leads and mediators of consensus.

    “Likewise, grafana/tempo [21] defines maintainers as both technical leads and mediators of consensus.”
    Quote in the paperNot a substantial claim0 of 1 sources checked
    • cites [21] [21] Grafana/tempo GitHub Project. 2025. Tempo. https://github.com/grafana/tempo. Accessed: 22 October 2025. -

      Not checked in the free run.

  • May combine two claims.

    Findingown data
    § 3.6 Manual Role Clustering Interpretation · p. 5

    Manual clustering yielded 133 role instances, with Core Maintainer (50) and Contributor (29) as the most frequent clusters.

    “| Core Maintainer | 50 | Advocacy | 4 | | Contributor | 29 | Emeritus Maintainer | 4 | | Steering | 20 | Triage | 3 | | User | 12 | Reviewer | 2 | | Project Specific | 9 | Committer | 1 | | Owner | 8 | | | | | |”
    Quote in the paperNot a substantial claim
    • Rests on an assumption: Written governance files provide an explicit and reliable record of how OSS projects define roles and distribute authority.
    • Rests on an assumption: The sampled GitHub repositories with governance files are representative of OSS projects more broadly.

  • May combine two claims.

    Findingown data
    § 3.2 Finding Candidate Projects · p. 3

    Across 8,000 sampled repositories, 72 (0.90%) contained governance files and 54 (0.67%) contained governance files with content.

    “| Total | 8,000 | 72(0.90%) | 54(0.67%) |”
    Quote in the paperSubstantial claim

  • May combine two claims.

    Findingnone given
    § 4.2 What's in a Role? Skills Tell the Story · p. 7

    Committers are tightly focused on programming (T1), but also commonly involve management and interpersonal skills, such as coordinating merges, communicating changes, and aligning contributions with project goals.

    “On the one side, committers are tightly focused on programming (T1), but also commonly involve management and interpersonal skills, such as coordinating merges, communicating changes, and aligning contributions with the project's goals.”
    Quote in the paperNot a substantial claim

  • May combine two claims.

    Findingcitation
    § 4.2 What's in a Role? Skills Tell the Story · p. 8

    In zellij-org/zellij, the BDFL is responsible for strategic decisions on finance and collaborations, retaining veto power as a safeguard for coordinating community decisions.

    “For instance, in the zellij-org/zellij project [57], the BDFL is responsible for strategic decisions on finance and collaborations, retaining the veto power as a safeguard for coordinating community decisions.”
    Quote in the paperNot a substantial claim0 of 1 sources checked
    • cites [57] [57] zellij-org/zellij GitHub Project. 2025. Zellij. https://github.com/zellij-org/zellij. Accessed: 22 October 2025. -

      Not checked in the free run.

  • May combine two claims.

    Findingcitation
    § 4.2 What's in a Role? Skills Tell the Story · p. 7

    In kopia/kopia, the commit-then-review process is described as efficient for trusted contributors, while their work continues to be reviewed by the community before acceptance.

    “The kopia/kopia project [25] describes this commit-then-review process as efficient for trusted contributors, while their work continues to be reviewed by the community before acceptance.”
    Quote in the paperNot a substantial claim0 of 1 sources checked
    • cites [25] [25] kopia/kopia GitHub Project. 2025. Kopia. https://github.com/kopia/kopia. Accessed: 22 October 2025. -

      Not checked in the free run.

  • Probably not a substantial claim: may not pass S4 (based).

    Premisereasoning
    § 1 Introduction · p. 1

    We still lack a clear understanding of how authority and responsibility are documented in OSS projects.

    “As a result, we still lack a clear understanding of how authority and responsibility are documented in OSS projects.”
    Quote in the paperNot a substantial claim

  • Probably not a substantial claim: may not pass S4 (based).

    Premisereasoning
    § 1 Introduction · p. 1

    Without systematic analysis of governance documents, authority distribution and how contributors gain or lose influence within different organizational structures remain unclear.

    “Without a systematic analysis of these governance documents, the authority distribution and how contributors gain or lose influence within different organizational structures remain unclear.”
    Quote in the paperNot a substantial claim

  • May combine two claims.

    Premisecitation
    § 1 Introduction · p. 1

    When governance mechanisms remain undefined, projects risk stagnation, contributor burnout, and a decline in trust.

    “When these governance mechanisms remain undefined, projects risk stagnation, contributor burnout, and a decline in trust.”
    Quote in the paperSubstantial claim0 of 1 sources checked
    • cites [51] [51] The Linux Foundation. 2023. Rising Tides of Open Source: Linux Foundation Annual Report 2023. https://www.linuxfoundation.org/hubfs/Reports/2023\_lf\_ annual\_report\_122123a.pdf. Accessed: October 21, 2025. -

      Not checked in the free run.

  • Probably not a substantial claim: may not pass S3 (load-bearing).

    Premisecitation
    § 2 Related Work · p. 2

    OSS has been conceptualized as a form of community of practice, where learning, legitimacy, and authority emerge through participation rather than formal appointment.

    “OSS has been conceptualized as a form of community of practice [26], where learning, legitimacy, and authority emerge through participation, rather than formal appointment.”
    Quote in the paperNot a substantial claim0 of 1 sources checked
    • cites [26] [26] Jean Lave and E Wenger. 1991. Learning in doing: Social, cognitive, and computational perspectives. Situated learning: Legitimate peripheral participation 10 (1991), 109-155. - source

  • Probably not a substantial claim: may not pass S4 (based).

    Premisenone given
    § Abstract · p. 1

    We lack systematic empirical evidence of how projects formally codify roles and authority in written artifacts.

    “We lack systematic empirical evidence of how projects formally codify roles and authority in written artifacts.”
    Quote in the paperNot a substantial claim

  • May combine two claims.

    Interpretationreasoning
    § ACMReference Format: · p. 2

    The inconsistencies in role labeling and definition reveal a persistent misalignment of terminology, a lack of definitions, and overlapping responsibilities.

    “These inconsistencies reveal a persistent misalignment of terminology, a lack of definitions, and overlapping responsibilities.”
    Quote in the paperSubstantial claim
    • Rests on an assumption: Written governance files provide an explicit and reliable record of how OSS projects define roles and distribute authority.
    • Rests on an assumption: The sampled GitHub repositories with governance files are representative of OSS projects more broadly.

  • Classified as probably not a substantial claim.

    Interpretationreasoning
    § 5.5 Implications for Governance Design · p. 9

    Symbolic and communicative roles reflect contributions that sustain community identity, cohesion, and continuity.

    “These position reflect contributions that sustain community identity, cohesion, and continuity.”
    Quote in the paperSubstantial claim

  • Probably not a substantial claim: may not pass S3 (load-bearing). May combine two claims.

    Study design and conductreasoning
    § 3.1 Researcher Positionality and Reflectivity · p. 3

    Insider familiarity offered understanding of governance language and practices but carried risk of interpretive bias.

    “This insider familiarity offered an interesting understanding of governance language and practices, but also carried the risk of interpretive bias.”
    Quote in the paperNot a substantial claim

  • Probably not a substantial claim: may not pass S3 (load-bearing).

    Interpretationreasoning
    § 4.2 What's in a Role? Skills Tell the Story · p. 9

    In governance terms, users are symbolic placeholders for the external audience that validates the project's value.

    “In governance terms, users are symbolic placeholders for the external audience that validates the project's value.”
    Quote in the paperNot a substantial claim

  • Probably not a substantial claim: may not pass S3 (load-bearing).

    Study design and conductreasoning
    § 3.1 Researcher Positionality and Reflectivity · p. 3

    To mitigate potential bias, the authors adopted a reflexive stance throughout the analysis.

    “To mitigate the potential bias, we adopted a reflexive stance throughout the analysis.”
    Quote in the paperNot a substantial claim

  • Classified as probably not a substantial claim.

    Study design and conductreasoning
    § 4.2 What's in a Role? Skills Tell the Story · p. 6

    Roles were classified into organizational or operational layers based on formal decision authority rather than the technicality of their tasks.

    “To ensure consistency, we classified roles into organizational or operational layers based on their formal decision authority rather than the technicality of their tasks.”
    Quote in the paperSubstantial claim

  • Probably not a substantial claim: may not pass S3 (load-bearing).

    Study design and conductnone given
    § 3.6 Manual Role Clustering Interpretation · p. 5

    Two of the authors have over a decade of experience studying OSS sustainability.

    “Two of them have over a decade of experience studying OSS sustainability, contributing extensive domain knowledge to the process.”
    Quote in the paperNot a substantial claim

  • Classified as probably not a substantial claim.

    Premisecitation
    § 2.3 Institutional Grammar · p. 2

    Institutional Grammar conceptualizes institutions as systems of statements that specify who may or must do what, under which conditions, and with what consequences.

    “IG conceptualizes institutions as systems of statements that specify who may or must do what, under which conditions, and with what consequences [9].”
    Quote in the paperSubstantial claim0 of 1 sources checked
    • cites [9] [9] Sue ES Crawford and Elinor Ostrom. 1995. A grammar of institutions. American political science review 89, 3 (1995), 582-600. - source

  • May combine two claims.

    Interpretationreasoning
    § 4.2 What's in a Role? Skills Tell the Story · p. 8

    Steering and owner roles embody governance as strategy rather than operation: they set direction, define policies, and coordinate with stakeholders.

    “These roles embody governance as strategy rather than operation: they set direction, define policies, and coordinate with stakeholders.”
    Quote in the paperSubstantial claim

  • Classified as probably not a substantial claim. May combine two claims.

    Study design and conductreasoning
    § 3.5 Mapping Titles to Talents · p. 5

    Recognizing the limitation of unstable clusters, the authors decided not to overinterpret them and instead advanced toward another analytical approach.

    “Recognizing this limitation, we decided not to overinterpret the unstable clusters and instead advance toward another analytical approach capable of capturing these composite role structures.”
    Quote in the paperSubstantial claim

  • May combine two claims.

    Interpretationreasoning
    § 4.2 What's in a Role? Skills Tell the Story · p. 7

    Maintainers are guardians of standards, planners of direction and vision, leaders, and often mentors.

    “They are guardians of standards, planners of direction and vision, leaders, and often mentors.”
    Quote in the paperNot a substantial claim

  • Probably not a substantial claim: may not pass S3 (load-bearing).

    Premisecitation
    § 3.2 Finding Candidate Projects · p. 3

    The population consists of OSS projects hosted on GitHub, one of the largest ecosystems for software development and collaboration.

    “Our population consists of OSS projects hosted on GitHub, which represents one of the largest ecosystems for software development and collaboration [16, 17].”
    Quote in the paperNot a substantial claim0 of 2 sources checked
    • cites [16] [16] GitHub. 2023. 100 Million Developers and Counting. https://github.blog/newsinsights/company-news/100-million-developers-and-counting/. Accessed: October 21, 2025. -

      Not checked in the free run.

    • cites [17] [17] GitHub. 2025. About GitHub - Where people build software. https://github.com/ about. Accessed: October 21, 2025. -

      Not checked in the free run.

  • Probably not a substantial claim: may not pass S2 (checkable). May combine two claims.

    Study design and conductreasoning
    § 6 Study Design Trade-Offs and Limitations · p. 10

    This increased interpretive judgment but allowed a richer understanding of how projects blend technical and organizational expertise.

    “This increased interpretive judgment but allowed a richer understanding of how projects blend technical and organizational expertise.”
    Quote in the paperNot a substantial claim

  • Probably not a substantial claim: may not pass S2 (checkable).

    Interpretationreasoning
    § 5.5 Implications for Governance Design · p. 9

    This structured representation enables consistent comparison across heterogeneous projects, moving analysis beyond informal titles or anecdotal accounts.

    “This structured representation enables consistent comparison across heterogeneous projects, moving analysis beyond informal titles or anecdotal accounts.”
    Quote in the paperNot a substantial claim

  • Probably not a substantial claim: may not pass S3 (load-bearing). May combine two claims. The quote only partly states this claim.

    Study design and conductown data
    § 3.6 Manual Role Clustering Interpretation · p. 5

    The interpretive clustering was conducted in one intensive session involving three authors, with decisions made only through unanimous agreement.

    “The interpretive clustering was conducted in one intensive session involving three of the authors. Two of them have over a decade of experience studying OSS sustainability, contributing extensive domain knowledge to the process. Each role identified per file was discussed collaboratively, one by one, examining its textual definition, skill composition, and possible alignment within the emerging”
    Quote in the paperNot a substantial claim

  • May combine two claims.

    Interpretationreasoning
    § 5.1 Governance as Textually Observable Infrastructure · p. 9

    Treating governance artifacts as primary data makes governance empirically observable and enables cross-project comparison.

    “By treating these artifacts as primary data, it is possible to analyze them through their textual form, much like source code or documentation. This perspective makes governance empirically observable and enables cross-project comparison.”
    Quote in the paperSubstantial claim

  • May combine two claims.

    Interpretationown data
    § 5.5 Implications for Governance Design · p. 9

    Maintainers often accumulate multiple responsibilities, where concentration of duties may hide dependencies and potential burnout.

    “Maintainers often accumulate multiple responsibilities, where the concentration of duties may hidden dependencies and potential burnout.”
    Quote in the paperSubstantial claim

  • Probably not a substantial claim: may not pass S2 (checkable).

    Interpretationreasoning
    § 5.5 Implications for Governance Design · p. 9

    This perspective complements interview- or activity-based studies by providing a stable, inspectable layer where institutional logic is explicitly recorded.

    “This perspective complements interview- or activity-based studies by providing a stable, inspectable layer where institutional logic is explicitly recorded.”
    Quote in the paperNot a substantial claim

  • Classified as probably not a substantial claim. May combine two claims.

    Study design and conductreasoning
    § 6 Study Design Trade-Offs and Limitations · p. 10

    Our analysis emphasizes descriptive and comparative interpretation; we deliberately avoid linking governance forms to project outcomes such as retention or success, as they would require different data and design strategies.

    “Our analysis emphasizes descriptive and comparative interpretation; we deliberately avoid linking governance forms to project outcomes such as retention or success, as they would require different data and design strategies.”
    Quote in the paperSubstantial claim

  • May combine two claims.

    Interpretationcitation
    § 4.2 What's in a Role? Skills Tell the Story · p. 8

    Unlike steering committees, whose power is collective, founders centralize decision-making.

    “Unlike steering committees, whose power is collective, founders centralize decision-making.”
    Quote in the paperNot a substantial claim

  • May combine two claims.

    Premisereasoning
    § 2.2 The (Lack of) Documented Governance · p. 2

    We still lack an empirical account of what responsibilities and decision structures OSS projects codify and how these vary across ecosystems.

    “We still lack an empirical account of what responsibilities and decision structures OSS projects codify, and how these vary across ecosystems.”
    Quote in the paperNot a substantial claim

  • Probably not a substantial claim: may not pass S3 (load-bearing). May combine two claims.

    Interpretationreasoning
    § 4.2 What's in a Role? Skills Tell the Story · p. 7

    Becoming a contributor is the entry point for participation, carrying productive or social obligations that may be fulfilled through one or more activities stated in the governance document.

    “In other words, becoming a contributor is the entry point for participation, carrying productive or social obligations that may be fulfilled through one or more activities stated in the governance document.”
    Quote in the paperNot a substantial claim

  • Probably not a substantial claim: may not pass S3 (load-bearing).

    Premisecitation
    § 3.2 Finding Candidate Projects · p. 3

    The selection of licenses is grounded in recent license popularity rankings reported by GitHub's Innovation Graph.

    “Our selection is grounded in the recent license popularity rankings reported by GitHub's Innovation Graph [19].”
    Quote in the paperNot a substantial claim0 of 1 sources checked
    • cites [19] [19] GitHub. 2025. License Rankings Globally. https://innovationgraph.github.com/ global-metrics/licenses Top Used OSS Licenses. -

      Not checked in the free run.

  • May combine two claims.

    Interpretationreasoning
    § 3.5 Mapping Titles to Talents · p. 5

    Hybrid roles inflated their skill bundles, causing them to appear artificially similar to multiple categories at once and undermining the convergence of the clustering.

    “These hybrid roles inflated their skill bundles, causing them to appear artificially similar to multiple categories at once and undermining the convergence of the clustering.”
    Quote in the paperSubstantial claim
    • Rests on an assumption: Written governance files provide an explicit and reliable record of how OSS projects define roles and distribute authority.

  • May combine two claims.

    Interpretationown data
    § 5.1 Governance as Textually Observable Infrastructure · p. 9

    The governance files analyzed here define who decides, who acts, and under what conditions, transforming tacit community norms into explicit, inspectable rules.

    “The governance files analyzed here define who decides, who acts, and under what conditions, transforming what might otherwise remain tacit community norms into explicit, inspectable rules.”
    Quote in the paperSubstantial claim

  • Classified as probably not a substantial claim. May combine two claims.

    Study design and conductreasoning
    § 6 Study Design Trade-Offs and Limitations · p. 10

    License stratification ensured broad ecosystem coverage, while star counts provided a reproducible, API-accessible indicator of visibility.

    “License stratification ensured broad ecosystem coverage, while star counts provided a reproducible, API-accessible indicator of visibility.”
    Quote in the paperSubstantial claim

  • May combine two claims.

    Interpretationown data
    § 5.1 Governance as Textually Observable Infrastructure · p. 9

    Governance in OSS projects is not only enacted through participation but also documented through written artifacts that make authority visible and comparable.

    “Our study demonstrates that governance in OSS projects is not only enacted through participation but also documented through written artifacts that make authority visible and comparable.”
    Quote in the paperSubstantial claim

  • Probably not a substantial claim: may not pass S2 (checkable).

    Interpretationreasoning
    § 5.5 Implications for Governance Design · p. 9

    By treating governance as textually observable infrastructure, researchers can systematically compare how authority and responsibility are formalized across projects.

    “By treating governance as textually observable infrastructure, researchers can systematically compare how authority and responsibility are formalized across projects.”
    Quote in the paperNot a substantial claim

  • Probably not a substantial claim: may not pass S3 (load-bearing). May combine two claims.

    Study design and conductnone given
    § 3.1 Researcher Positionality and Reflectivity · p. 3

    The study was conducted by researchers with long-standing involvement in OSS communities and experience studying sociotechnical collaboration.

    “This study was conducted by researchers with long-standing involvement in OSS communities and experience studying sociotechnical collaboration. All the authors have experience in conducting empirical studies on OSS community governance, onboarding, and sustainability.”
    Quote in the paperNot a substantial claim

  • Probably not a substantial claim: may not pass S3 (load-bearing).

    Study design and conductreasoning
    § 3.1 Researcher Positionality and Reflectivity · p. 3

    Iterative peer debriefing among the authors helped ensure that decisions about role categorization and skill mapping reflected the actual data.

    “Iterative peer debriefing among the authors helped ensure that decisions about role categorization and skill mapping reflected the actual data.”
    Quote in the paperNot a substantial claim

  • Classified as probably not a substantial claim.

    Study design and conductown data
    § 3.6 Manual Role Clustering Interpretation · p. 5

    Each role identified per file was discussed collaboratively, one by one, examining its textual definition, skill composition, and possible alignment within the emerging clusters.

    “Each role identified per file was discussed collaboratively, one by one, examining its textual definition, skill composition, and possible alignment within the emerging clusters.”
    Quote in the paperSubstantial claim

  • Classified as probably not a substantial claim.

    Premisecitation
    § 2.3 Institutional Grammar · p. 2

    Each institutional statement can be decomposed into Attribute, Deontic, Aim/Object, Conditions, and Or-else components.

    “To enable systematic analysis, each institutional statement can be decomposed into syntactic components, commonly summarized as Attribute (actor), Deontic (permission, obligation, or prohibition), Aim/Object (action), Conditions (context), and Or-else (sanction).”
    Quote in the paperSubstantial claim0 of 1 sources checked
    • cites [47] [47] Saba Siddiki, Christopher M Weible, Xavier Basurto, and John Calanni. 2011. Dissecting policy designs: An application of the institutional grammar tool. Policy Studies Journal 39, 1 (2011), 79-103. - source

  • Probably not a substantial claim: may not pass S2 (checkable).

    Interpretationreasoning
    § 5.5 Implications for Governance Design · p. 9

    Governance artifacts constitute a rich and underutilized source of empirical evidence.

    “this work suggests that governance artifacts themselves constitute a rich and underutilized source of empirical evidence .”
    Quote in the paperNot a substantial claim

  • Classified as probably not a substantial claim.

    Study design and conductown data
    § 6 Study Design Trade-Offs and Limitations · p. 10

    We initially applied unsupervised clustering to group roles, but found that composite or overlapping roles produced unstable results.

    “we initially applied unsupervised clustering to group roles, but found that composite or overlapping roles produced unstable results.”
    Quote in the paperSubstantial claim

  • Probably not a substantial claim: may not pass S2 (checkable), S4 (based).

    Premisenone given
    § 3.6 Manual Role Clustering Interpretation · p. 5

    Governance roles are complex social artifacts embedded in community norms, historical trajectories, and project-specific practices that resist purely computational classification.

    “The next step was a manual interpretive clustering process, recognizing that governance roles are complex social artifacts. They are embedded in community norms, historical trajectories, and projectspecific practices that resist purely computational classification.”
    Quote in the paperNot a substantial claim
    • Rests on an assumption: The sampled GitHub repositories with governance files are representative of OSS projects more broadly.

  • May combine two claims.

    Interpretationreasoning
    § 4.2 What's in a Role? Skills Tell the Story · p. 7

    Maintainers have a multi-dimensional mandate: ensuring technical quality and leading the community.

    “This breadth reflects their multi-dimensional mandate, ensuring technical quality and leading the community.”
    Quote in the paperSubstantial claim

  • Classified as probably not a substantial claim.

    Study design and conductreasoning
    § 6 Study Design Trade-Offs and Limitations · p. 10

    Our results characterize governance as it is written, not necessarily as it is enacted.

    “Our results, therefore, characterize governance as it is written, not necessarily as it is enacted.”
    Quote in the paperSubstantial claim

  • May combine two claims.

    Study design and conductreasoning
    § 3.6 Manual Role Clustering Interpretation · p. 5

    The interpretive approach (manual interpretive clustering) was more effective, though more time-consuming, than automatic clustering because it accommodated the composite nature of governance roles.

    “This interpretive approach was more effective, although more time-consuming, than automatic clustering because it could accommodate the composite nature of governance roles.”
    Quote in the paperSubstantial claim

  • Classified as probably not a substantial claim.

    Study design and conductreasoning
    § 6 Study Design Trade-Offs and Limitations · p. 10

    We pivoted to manual interpretive clustering, conducted collaboratively among authors and refined through consensus discussions.

    “We therefore pivoted to manual interpretive clustering, conducted collaboratively among authors and refined through consensus discussions.”
    Quote in the paperSubstantial claim

  • Classified as probably not a substantial claim.

    Interpretationreasoning
    § 7 Conclusion · p. 10

    Governance files such as GOVERNANCE.md serve as socio-technical blueprints that document institutional arrangements that make participation pathways visible.

    “Governance files such as GOVERNANCE.md serve as socio-technical blueprints that document institutional arrangements that make participation pathways visible.”
    Quote in the paperSubstantial claim
71 of 71

  • The paper relies on this without support.

    Written governance files provide an explicit and reliable record of how OSS projects define roles and distribute authority.

    “Governance artifacts (such as GOVERNANCE.md fi les) offer an explicit record of how communities describe participation.”
    “Governance files represent one of the publicly accessible traces of how communities formalize who participates, the responsibilities they have, and under what conditions.”

  • The paper relies on this without support.

    The sampled GitHub repositories with governance files are representative of OSS projects more broadly.

    “Our population consists of OSS projects hosted on GitHub, which represents one of the largest ecosystems for software development and collaboration [16, 17].”
    “Based on these criteria, we collected a license-stratified set of projects on GitHub.”
2 of 2

Self-check

Percentages, sums and reported differences re-computed from the paper’s own numbers.

Each contradiction between two passages listed here was confirmed by an independent check.

  • Role-cluster sizes exceed the reported total

    Major

    The cluster sizes in Table 4 sum to 142 role instances, not 133. This changes the reported size of the role analysis.

    Reported 133 · recomputed 142

  • Sampling description lists more license categories than Table 1 reports

    Major

    The methods list 11 license categories and say 1,000 repositories were retrieved under each, but Table 1 reports a total of 8,000 projects across only eight categories. GPL-2.0, GPL-3.0, and EPL-2.0 are absent from the table.

  • Governance-file content total does not match license rows

    Minor

    The eight entries in Table 1's "Governance Files w/ Content" column sum to 53, not the reported 54.

    Reported 54 · recomputed 53

3 of 3

Cites

Flagged first, then by citations

29 of the 58 references couldn’t be matched to a known paper.

Cited by

Sorted by citations

Related

Authors
Oliveira, P., Conte, T., Gerosa, M., & Steinmacher, I.
Affiliations
  • Northern Arizona University (US)
  • Universidade Federal do Amazonas (BR)
ORCID
Venue
Proceedings of the 19th International Conference on Cooperative and Human Aspects of Software Engineering
Publisher
ACM
Published
2026-04-12
Pages
255-266
DOI
10.1145/3794860.3794911
OpenAlex
W7142402513
Semantic Scholar
c1205d0645300da52b780762ac1ffac396e978fd
Cited by
2
References
58
Citations by year
2026: 2
FWCI
31.18
Type
conference paper
Language
en
Open access
Licence
Locations
  • International Workshop on Cooperative and Human Aspects of Software Engineering (CHASE) (publishedVersion, cc-by)
  • arXiv (Cornell University) (submittedVersion, cc-by)
  • arXiv (Cornell University) (cc-by)
Funders
  • CNPq (314797/2023-8, 443934/2023-1)
  • National Science Foundation (2303612)
Topics
  • Physical Sciences › Computer Science › Computer Science Applications › Open Source Software Innovations
  • Physical Sciences › Computer Science › Information Systems › Software Engineering Techniques and Practices
  • Physical Sciences › Computer Science › Information Systems › Software Engineering Research
Keywords
open source software, project governance, role definition, institutional grammar, decision rights, community leadership, GitHub repositories

About these checks

Registry, retraction, Cites and statistics results are computed, not judged, with one exception: a printed reference that no index lists is read once by a model before it counts as a citation error. Claims are extracted by a model and kept only when their quote appears verbatim in the text; each cited source is then checked, with a model’s help, for whether it says what the claim relies on. Those verdicts can be wrong — read the claim’s quote and the cited source before relying on one.

Claims read by deepseek-v4.1-flash under definition version 3 (extract-v3) on 2026-11-02.

Classified by jev-1.13-20260917 (gold-guideline-v0.2) on 2026-11-02.

Cited sources are checked by gpt-6-sol.

Statistics and arithmetic are recomputed, not judged.

Confidence bands are shown only for fields calibrated on our annotated test set. None is calibrated yet, so no band is shown.

What counts as a claim ›How we measure confidence ›How we check this ›

Are you an author, or do you see a problem with this page? Request a review