Proposal: Redefining Contributions and Introducing Collaboration Metrics

[jonathimer]

We’re planning an update to how Insights classifies and displays activity types across platforms. The background is that contributor counts and leaderboards are sometimes misleading or gamed by low-effort activity. At the same time, we want to highlight and appreciate the many forms of non-code contributions that help open source communities thrive.

The change involves two key changes:

1. Refining what we count as a "Contribution"
   Not all activity currently labeled as a contribution should be counted as one. We aim to better reflect meaningful technical and community-driven impact.

2. Introducing a new category: "Collaboration"
   Some activities signal engagement or coordination rather than direct contributions. These will be grouped under a new Collaboration category.

Below you can find a detailed list of activity types that we plan to count as either Contribution or Collaboration going forward. Please let us know if you have any feedback or suggestions. 🙏

Suggested new categorization for activities

Code Contributions

Direct code contributions to the project, such as commits, pull requests, and code reviews.

Git
authored-commit
reviewed-commit
tested-commit
co-authored-commit
informed-commit
influenced-commit
approved-commit
committed-commit
reported-commit
resolved-commit
signed-off-commit

GitHub
pull_request-opened
pull_request-closed
pull_request-review-requested
pull_request-reviewed
pull_request-merged
pull_request-comment
authored-commit

Gerrit
changeset-new
changeset-created
changeset-merged
changeset-closed
changeset-abandoned
changeset_comment-created
patchset-created
patchset_comment-created
patchset_approval-created

GitLab
merge_request-opened
merge_request-closed
merge_request-review-requested
merge_request-review-approved
merge_request-review-changes-requested
merge_request-merged
merge_request-comment

Collaboration

Non-code contributions that support the project, including discussions, documentation, planning, and community engagement.

GitHub
discussion-started
issues-opened
issues-closed
issue-comment
discussion-comment

GitLab
issues-opened
issues-closed
issue-comment
authored-commit

Confluence
page-created
page-updated
comment-created
attachment-created
blogpost-created
blogpost-updated
attachment
comment

Jira
issue-created
issue-closed
issue-assigned
issue-updated
issue-comment-created
issue-comment-updated
issue-attachment-added

Groups.io
message

Discord
message
thread_started
thread_message

Slack
message

Stack Overflow
question
answer

[mrbobbytables]

I'm hesitant to separate issues from contributions. While there can be low effort issues they are frequently relevant and do require a good amount of thinking that refines the code contribution. Alternatively, I'd be explicit and instead of contributions, call them code contributions or code activities - something that signifies what they are.

[jonathimer]

Thanks for your feedback!

I agree that issues are an edge case. We also discussed this internally for a while. The same argument could be applied to mailing list messages, Confluence pages, etc.. The idea of "collaboration" was to create a place for these kind of contributions that allow us to highlight them (e.g. on leaderboards) but also differentiates them from code contributions.

I think calling it "code contributions" is a great suggestion to making the term more clear.

[caniszczyk]

The line of non-code and code contributions for issues is interesting as there tends to be a lot of technical discussion in issues. It does depend on the project, mature projects like Kubernetes tend to have a lot of technical discussion that happens in an issue.

I do like the direction this is going.

[caniszczyk]

Also one thing that may be missing is GitHub project management related events which I don't know if GitHub allows you to get that data via an API yet or not. JIRA and GitLab project boards fall under here too. This would fall under the "Collaboration" bucket

[jonathimer]

Right now, we don't get these kind of events from GitHub. I believe because GH doesn't expose them via API.

But totally agree that any kind of project management activity should go into Collaborations!

[krook]

I think issues can be used for a wide variety of purposes from a bug report, to a feature request, to work items on a project board. It's probably a standardized label or other metadata that would give the context about whether an issue is more of a contribution than a colllaboration.

[opoupeney]

+1 to the initiative

QQ: are GitHub reactions tracked as well (part of comments?), if so, will it be part of code contributions (if not associated to an issue’s comment)?

[Aditya30ag]

💡 Suggestions

1. Three-Tier Contribution Model
   Move beyond binary classification:
   Code: PRs, commits, reviews
   Technical: issues, docs, deep discussions
   Collaboration: Q&A, general chat, reactions

[opoupeney]

Are comments and reactions on PRs part of code contributions or collaboration?

[Aditya30ag]

Great question! Comments and reactions on PRs typically fall under Collaboration they foster communication, alignment, and support among contributors. However, if a comment includes substantive technical feedback or code-level suggestions, it may also touch on the Technical category

[opoupeney]

Absolutely @Aditya30ag , that's exactly what I wanted to bring up. Some dev oriented comments are pure suggestions for contributions. The following commits/PR revisions in the sequence of events would generally include these suggestions when done by a lead developer.
An other way would be to separate project collaboration and code collaboration under the collaboration category, if all comments/reactions go under that category.

[Aditya30ag]

I like the idea of splitting Collaboration into Project Collaboration and Code Collaboration

[lizrice]

It seems that the (worthy) goal here is to avoid counting low-effort / gamified contributions. Are there any data or worked examples to show how this breakdown would help separate out those activities? To be honest I don't really see how that's really addressed by splitting out code and non-code contributions. The gamification of trivial code contributions can be a real drain on maintainers (and explain why a lot of projects only try Hacktoberfest once!); AI-slop contributions are another current problem.

The other question I have about this is how the data will be interpreted, especially for projects trying to move up the CNCF maturity model. It would be a shame if only code contributions count when assessing how many organizations are putting effort into a project.