I Added One Field to Magento Core — Here’s Everything That Happened

The category edit page in Magento admin shows the category ID. The category tree does not. That means every time you need an ID for external system mapping, a layout XML target, or URL rewrite debugging, you click into the category, read one number, and click back out.

It is a tiny annoyance, but it happens every day. This article explains how that annoyance became a real merged pull request in magento/magento2, and what actually happens after you click create pull request.

The PR this article follows is magento/magento2#25717.

lead

This is for Magento engineers who want to contribute upstream but have never seen the full path between idea and release. You will see the real workflow gates and the practical decisions that keep a small PR moving.

baseline

A practical baseline is simple: pick one recurring friction point, make a small consistent fix, and present it with clear reasoning and reproducible tests. For this case, the baseline issue was category ID visibility in the admin tree.

1. The itch and why it is worth fixing

Not every core contribution needs to be a huge feature. Most useful contributions fit into one of three types:

• Bug fixes where behavior is clearly wrong.
• New features where capability does not exist yet.
• Quality of life improvements where daily friction is removed.

This change was quality of life. Nothing was broken. The ID was available, just in the wrong place for day to day work. That is still a valid reason to improve core.

The best first contribution is often your own recurring pain point. You already understand the context, you know what good looks like, and you can answer the review question why does this matter with real usage examples instead of theory.

2. Check if it already exists

Before writing code, search open and closed issues and pull requests. Closed discussions are often the fastest way to learn why an idea was rejected or what constraints maintainers care about.

For larger behavior changes or new feature work, open an issue first and align on direction. For small and obviously consistent UI improvements, a focused PR can be enough.

tradeoff

The tradeoff is speed now versus coordination later. Going straight to code can be fast, but without prior context you risk duplicate effort or rejection. Opening an issue first improves alignment but adds upfront time. For tiny consistency fixes, direct PR is often reasonable; for behavioral changes, issue first is safer.

3. One time setup that blocks many first PRs

You need a GitHub account and a fork of magento/magento2. Magento uses fork and pull workflow, so your branch lives on your fork and targets Magento develop.

You also need the Adobe CLA signed. This is the most common hidden blocker for first time contributors. Sign once and then you are done.

Enable GitHub 2FA as well. After your first PR, you may receive Magento org invitation flow that unlocks issue claiming and smoother contribution handling.

4. The actual code change

The fix itself was small. It touched one method that builds category tree labels in admin and aligned output with the existing title style that already includes ID.

The important mechanics around a tiny change are:

• Create a dedicated branch on your fork.
• Target the correct develop branch for the active release line.
• Follow existing conventions so reviewers see consistency instead of novelty.

When your change matches existing behavior in another place, review friction drops immediately.

5. Pull request structure that speeds review

A strong PR description does three things:

1. Explain the why, not only the what.
2. Provide reproducible manual test steps.
3. Show checklist discipline for quality and test coverage.

For this contribution the test scenario was simple: open Catalog to Categories and verify each tree item now includes category ID the same way the title does.

The easier your review path is, the faster maintainers can approve.

6. What happens after submit

After submission, automation and human workflow started:

• @magento bot posted commands and workflow guidance.
• CI checks ran and needed to pass.
• QA gate confirmation was posted.
• Community maintainer reviewed.
• Internal ENGCOM ticket was created.
• Engcom team merged into develop.

From outside, this can look opaque. In reality it is a sequence of explicit gates, each with different owners.

7. The real timeline is mostly waiting

The surprising part is not coding time, it is waiting time.

In this specific case, review and merge were fast, but release delivery was much slower. The change merged quickly into develop and still waited for the release train before reaching stores.

This is normal. You should separate two timelines:

• Review queue timeline, unpredictable.
• Release cadence timeline, predictable but slower.

Silence does not automatically mean rejection. Usually it means queueing or release staging.

One lever you do have: community votes

Magento prioritization is influenced by visible demand. Reactions and linked issues can increase priority signal for maintainers.

Practical approach:

• Link PR to an existing issue when possible.
• Open issue first when none exists.
• Use reactions instead of noisy plus one comments.

Votes do not override technical quality, but they can affect sequencing between similarly solid contributions.

working_example

A practical contribution loop that works:

1. Capture one concrete pain point from daily work.
2. Build the smallest change that aligns with existing behavior.
3. Write a PR description with context and manual verification steps.
4. Respond quickly to maintainer feedback.
5. Track release milestone and communicate expected ship timing.

8. Ship now, upstream in parallel

If you need behavior immediately, ship a local module while upstream PR moves through process.

If extension point is public, plugin is usually clean and removable later.

If extension point is not pluginable, class preference can work but increases maintenance risk.

That tradeoff itself is a reason to upstream: once core ships your behavior, you can delete local override and reduce long term fragility.

verification

You know this workflow worked when:

• The PR has reproducible test steps and a clear why.
• CI and QA gates are green.
• Maintainer feedback is resolved without long silence.
• The merge lands in develop.
• The change appears in the targeted release line.

Letting an AI agent help with tests

A practical place for AI support is test scaffolding. New contributors often stall on framework specific testing patterns even when they fully understand the fix itself.

A useful workflow is:

1. Write the fix yourself.
2. Ask AI to draft tests matching nearby module patterns.
3. Revert the fix and confirm tests fail.
4. Restore fix and confirm tests pass.

Never submit generated tests blindly. You should be able to explain each assertion and why it would fail when behavior regresses.

AI can lower activation energy, but quality bar stays exactly the same.

The takeaway

The code is usually the easy part. Contribution confidence comes from understanding the gates between idea and release: CLA, branch targeting, automation, QA, maintainer review, internal ticketing, merge, and release train.

The next time a repeated Magento friction point shows up in your daily work, treat it as a contribution candidate. Small, focused improvements are often the best first core PRs.