Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

Improve GitHub Contributor Selection and Cutoff Controls

未关闭
  • 哪里不对？
#78 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 8 天内回复

还没有人认领这个 Issue。

评估

难度
5/5
预计耗时
一周以上
新手友好度
15/100
Issue 类型
功能
描述清晰度
需要澄清
活跃度
活跃
技术栈
github, javascript
领域
tooling

调研方向

The payload names no files, so start by searching the codebase for where GitHub contributors are fetched, ranked by commit count and trimmed to a list. Then check how fork status is read from the GitHub API. Done means a written evaluation and recommendation covering the four acceptance criteria, with trade-offs for configurable limits, date or commit cutoffs, and fork-based history detection. This is design work, so ask the maintainers to confirm scope before writing any code.

由索引模型根据 Issue 内容生成。

描述

Improve GitHub Contributor Selection and Cutoff Controls

Description

OpenCite uses GitHub contributor information to supplement citation metadata, but the current contributor ranking and selection process may not always surface the most relevant people for a project.

Commit counts do not necessarily reflect authorship or the significance of someone's contributions. This becomes especially challenging when a repository is forked, cloned, or adapted from an existing project, since its history may include contributors who worked on the original project rather than the current one.

For example, a researcher may build on an existing repository while retaining some of its history, or a repository may no longer be recognized by GitHub as a fork. In these cases, it may be difficult to distinguish contributors to the original project from those who contributed to the current project.

Questions to Investigate

  • How should OpenCite determine which GitHub contributors to surface, and how many should be shown by default?
  • Could users configure the number of contributors or apply a cutoff to the contribution history?
  • Would a date cutoff or specific commit hash help distinguish relevant contributors from inherited project history?
  • Can GitHub's fork metadata or commit history help identify where independent development began?
  • How should OpenCite handle repositories that originated from another project but are no longer recognized as forks?
  • Could OpenCite provide more context about why a contributor was surfaced, rather than relying primarily on commit counts?

Potential Direction

Investigate configurable contributor selection and history-based cutoffs, including whether repository fork information can help identify the relevant contribution history.

The goal is to give users more control over which contributors are surfaced as potential authors, particularly for projects that build on existing repositories, without assuming that commit activity alone determines authorship.

Acceptance Criteria

  • Evaluate the limitations of the current contributor ranking and selection behavior.
  • Investigate the feasibility of configurable contributor limits and date/commit cutoffs.
  • Assess whether fork metadata and commit history can help distinguish inherited contributions from project-specific contributions.
  • Recommend an approach for improving contributor selection, including relevant trade-offs.
主要语言
JavaScript
星标
0
派生
0
平均合并
10 天 7 小时
30 天内合并 PR
3

环境准备

  • 没有 Dockerfile 或 Docker Compose 文件
  • 没有 Pull Request 模板
  • 阅读贡献指南

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

Imageomics/OpenCite 的其他 Issue

查看 Imageomics/OpenCite 的全部 Issue

相似的 Issue

更多 JavaScript Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。