Core contributor
A core contributor is someone whose work on Drupal core is accepted and credited: code, testing, review, documentation or triage on Drupal.org.
A core contributor is a person who has worked on Drupal core, the shared code under every Drupal site. The work can be code, but it can also be testing a fix, reviewing a change, triaging a bug report or writing documentation. When the issue is fixed, Drupal.org credits the people who moved it forward.
How core contribution works
Anyone with a Drupal.org account can be a core contributor by taking part in the core issue queue. Work happens in issues on Drupal.org. The contributor guide lists ongoing roles, such as software tester, usability group member and documentation editor, and one-off tasks, most of them 20 minutes to an hour long:
- triage an issue report
- create a merge request for an issue
- review another developer's merge request
- manually test a proposed fix
- write automated PHP test code for an issue
- write a change record or release notes
The finished work is reviewed by the community, and a core committer makes the final call and commits it.
How credit works
Your contribution is recognized once the issue is marked fixed or closed, and only if you attribute it. Comments are credited to you as an individual by default. To credit an employer or customer, open the Contribution record on the issue and choose between volunteering your own time and attributing the work to organizations or customers.
On core issues the committers review the credit that Drupal.org suggests and may add or remove names. The credit guidelines say work earns credit when it moves the issue forward. Examples they list are useful issue reports, new patches, improvements to a previous patch, substantial issue summary updates, thoughtful triage, manual testing with documented results, design or accessibility work, and non-trivial code reviews.
Example
A content editor finds that a core form shows an unclear message. She files an issue with steps to reproduce and a screenshot. A developer writes a fix, and she tests it by hand and documents the result in a comment. When a committer merges the change, both can be credited, and she can attribute her time to her employer through the Contribution record.
Common mistakes
- Posting looks good on an issue. A comment with no substance usually earns no credit. Say what you tested, on which version, and what you saw.
- Rerolling or reposting a patch without need. Unneeded rerolls and repeated work do not move the issue forward.
- Submitting AI output unchecked. The guidelines say AI-generated comments or code usually earn no credit when the contributor neither states which AI was used nor reviewed or tested the result locally. State the tool and test the result.
- Forgetting attribution. Credit for an organization is set per issue. If you skip the Contribution record, the work is credited to you alone.
For marketing and content teams
You do not need to be a developer. Triage, manual testing and accessibility or usability feedback are on the task list, and editors know where the interface confuses people. A company that gives staff time to core can show that work through attribution, which ties the organization to the issues it supported. Work on contributed modules is a separate area of contribution.