Navigating Attribution in Software Projects: When Co-Authorship Goes Awry

Open-source contributions are the lifeblood of many software projects, fostering innovation and community. However, the intricacies of attribution, especially in an era of AI-assisted development, can sometimes lead to unexpected and frustrating situations. A recent GitHub Community discussion highlights a critical challenge: what happens when your contributions are re-authored, potentially with AI, and attributed to you without consent?

The Unwanted Co-Authorship Dilemma

The discussion, initiated by user ssakkout, details a concerning incident involving a pull request (PR) to fix dependency errors in a project. After ssakkout opened PR 1393, the project maintainer subsequently opened a new PR (1397) incorporating ssakkout's changes. The twist? The maintainer attributed a key change (adding torchvision) to "claude" (an AI) and added ssakkout as a co-author for another part (torchcodec) – all without ssakkout's explicit consent.

This action resulted in an unwanted "pair extraordinare" badge on ssakkout's GitHub profile, linking them as a co-author with an AI. Ssakkout, who explicitly stated they did not use AI for their changes and requested removal from co-authorship multiple times, found their requests ignored. The core of their frustration was not just the misattribution but the lack of control over their public profile and the appearance of collaboration with AI when none occurred.

Understanding GitHub's Attribution System

As RAAJK20Pro clarified in the discussion, GitHub's co-author and pair-programming attribution system is largely automated. It's driven by commit metadata, specifically lines like:

Co-authored-by: username 

If such metadata is included in merged commits, GitHub automatically associates the accounts and generates the relevant badges. This means the maintainer didn't manually "assign" a badge but rather included metadata that triggered GitHub's automated system. While technically "behaving as designed," this system lacks a crucial element: user consent.

Navigating Consent and Control in Development Activity Examples

This incident underscores a gap in current platform capabilities and raises important questions about developer autonomy. For maintainers, while the intent might have been to streamline the merge process or credit contributors, the method chosen overlooked critical aspects of collaboration ethics. Better development activity examples would include:

• Continuing work directly on the original PR, allowing the contributor to remain in control.
• Opening a replacement PR but carefully managing commit messages to avoid unwanted co-author metadata.
• Squashing commits and editing messages before merging to ensure accurate attribution.
• Manually crediting contributors in the PR description rather than through commit metadata if consent for co-authorship isn't obtained.

These practices contribute to positive software engineer performance goals by fostering trust and respecting individual contributions.

The Path Forward: Enhancing Developer Control

The discussion highlights a clear need for GitHub to evolve its attribution features. Ideal improvements would include:

• The ability for users to explicitly reject co-author attribution.
• Granular control to remove specific pair-programming badges or hide individual contribution associations.
• A mechanism requiring explicit approval before public co-author attribution appears on profiles.

Such features would empower developers to maintain accurate and desired representations of their work, ensuring that attribution truly reflects their contributions and consent in collaborative software projects.