How credit is granted for Drupal core issues

Drupal core committers are responsible for ensuring that contributors are credited fairly on an issue and ultimately decide how to grant credit on the basis of a review of user activity on the issue.

Guidelines for granting issue credit

1. Good intentions are assumed from each contributor. All of us began as beginners and we know that there is always a learning process.

2. Contributions must help to move the issue forward to receive credit. The repetition of previous tasks will not be credited.

3. Core committers strive to provide constructive feedback and encourage an environment where constructive feedback is the norm.

4. Core committers believe in mentoring contributors and may provide guidance to aid with more helpful contributions in the future.

5. Core committers manually review the credit suggested by the Drupal.org user interface to subtract from and/or add to the list.

6. Core committers should transfer credit from issues marked as duplicate to the issue remaining open.

7. When a user repeatedly posts low-quality contributions, the user's contact form may be used to reach out to them about best practices and to help them find a way to productively contribute.

Examples of contributions that usually receive credit

• Useful original issue report
• A new patch
• Productive improvements to a previous patch
• Resolving a merge conflict when rerolling, rebasing, or merging HEAD
  • Document the merge conflict diff on the issue in a <code> tag. 
• Substantial issue summary update
• Thoughtful triage evaluation (including issue priority discussions for core issues)
  • Document the reason for the priority change and all participants in the decision.
• Participation in an off-issue (Slack, in-person, etc.) discussion leading to a decision for the issue
  • Document all participants in the discussion and its conclusion. 
• Mentoring
• Mentored contribution event participation
  • Document the mentor and all active participants at the table in an issue comment.
• Screenshots that illustrate the bug or the change
• Manual testing with specific documentation of how the patch was tested and what the results were
• Design, usability, or accessibility work or review
• Code review
  • Non-trivial code reviews, including committer reviews
  • For trivial or coding standards code reviews, only reviews that also take the time to provide mentoring and references for patch contributors
  • Reviews that result in changes to the patch or issue scope (where appropriate)

Examples of what will usually not receive credit

• AI-generated comments or code that does not state the AI used and that has not been reviewed and/or tested locally.
• Creating a fork for an issue that does not need one.
• Creating an MR or fork without changes or further involvement in resolving the issue.
• Accepting another contributor's merge request suggestions without further involvement in resolving the issue.
• Small metadata fixes, retesting patches, etc.
• Small issue summary update (changing a few words or a bullet point)
• Boilerplate triage evaluations that don't include detail
• Small nitpick-only reviews
• Review or RTBC with only comments like:
  • "Patch applies to 8.0.x in my local environment."
  • "Setting RTBC".
  • "I tested the patch and it works fine."
  • "This resolves the issue."
  • "Reviewed and tested patch. All three use cases work as intended."
  • "Looks good."
  • "Didn't find anything wrong with it."
  • "RTBC +1"
• Unhelpful comments
  • Unrelated comments
  • Simple questions that do not affect the issue or followups for it
  • Rants (i.e. it's not just any long comment that merits credit -- just constructive/helpful ones)
  • Requests for support
  • Comments like "I am encountering this bug on Drupal 7.24"
    • Exception: When it's actually necessary to confirm that a bug still exists
• Unhelpful or barely-helpful patches
  • Patches that are identical to a previous patch by a different contributor
  • Patches that disregard feedback or discussion on the issue
  • Unneeded or incorrect patch rerolls
  • Rerolling, rebasing, or merging HEAD when there are no merge conflicts
  • Opening a new issue fork or merge request with no changes of your own
  • Reposting existing patches (including coding standard cleanup patches generated by DrupalCI)
  • Converting an existing patch to a merge request with no changes of your own
• Unhelpful file attachments or screenshots, e.g.:
  • Any screenshots for a patch that does not make any user-facing changes
  • Screenshots of the patch applied in your IDE (these are never helpful)
  • Screenshots of pages that don't have anything to do with the patch
  • Duplicate screenshots where someone else has already provided the required screenshots

What to do if you believe there is a mistake in issue crediting

Begin with a review of the above guidelines and examples to confirm that you or someone else should have received credit for an issue or that someone received credit erroneously. If, after the review, you still think there is an error then contact the committer who committed the issue and discuss the matter with them.

Committers can fix issue credit after the commit (even if the commit message cannot be changed anymore). In serious cases, committers may decide to roll back an issue and commit with the corrected credits.

How contributors can be credited on Drupal.org

Getting credit for work on issues explains how to attribute your work.