How to Make Your First Open-Source Contribution: TencentDB Agent Memory

Open-source project: TencentDB Agent Memory

When preparing to contribute to open source for the first time, many people head straight for the source code. The more files they open, the more questions they have: Do I need to understand the entire project? Does a contribution have to involve code? Would fixing a small issue really matter?

My advice is to start with a problem you can explain, verify, and follow through on.

I care more about whether a contribution helps someone else continue the work. A reproducible bug report, an integration example that actually runs, or a proposal that explains its tradeoffs can move a project forward. Lines of code are a poor measure of contribution value.

Using TencentDB Agent Memory as an example, this article explains how to turn an intention to participate into concrete collaboration. The project's Community Contribution and Collaboration Guide describes participation routes, branch purposes, and community responsibilities. It is a useful starting point.

Use the project and find a real problem

TencentDB Agent Memory is an open-source memory project for AI agents. It offers personal and team memory, helping agents preserve, organize, and reuse conversations, task experience, documentation, and code. Team memory centers on four asset types: Chat Memory, Skill, Wiki, and CodeGraph, with sharing, access control, and agent-specific asset assignments.

There are many ways to explore it. Connect an agent client you already use, import a project document, create a team, or use the SDK to write and retrieve a memory. Completing one real workflow is a good way to discover a concrete contribution opportunity.

Does an integration tutorial explain all its prerequisites? Does an error message help a user identify the cause? Does an example run in the environment specified by the documentation? These are useful questions to investigate, rather than claims that the project already has those problems.

You do not need to begin by changing the core algorithms. Reproduction steps, checks of English and Chinese documentation, and integration validation can all be meaningful contributions. The project's definition of a Contributor includes code, documentation, reproduction, tests, practical use cases, and useful review feedback.

Check the branch and scope before choosing a task

Branch selection matters in this repository. According to the current contribution guide:

• main focuses on personal memory through plugin integrations for OpenClaw and Hermes.
• feat/server focuses on personal memory through standalone services, HTTP APIs, and SDKs.
• feat/server_team focuses on team memory, asset collaboration, access control, Memory Hub, and Proxy capabilities.

The current default development branch is feat/server_team, and PRs should normally target it. Use main or feat/server only when maintainers direct your change there. For work on personal memory or changes spanning several branches, confirm the scope in the related issue first. Always check the latest guidance when you start, because development arrangements can change.

Next, look through the issues:

• good first issue identifies tasks suitable for newcomers, with a clear scope and acceptance criteria.
• help wanted invites community collaboration and usually requires some project familiarity.
• need-reproduction calls for minimal examples, environment comparisons, or validation results.
• need-design means the design still needs agreement; proposals and tradeoff analysis are useful here.

A label is an entry point. The full discussion determines what needs to happen. Before taking a task, I would read the expected behavior, acceptance criteria, existing proposals, and any participation restrictions, then check whether someone is already working on it.

For example, you could leave a comment like this:

I'd like to help with this issue. I'll first reproduce it using the reported version and environment, confirm the scope, and propose a change. For now, I plan to address the configuration instructions in the integration documentation. If the investigation points to a code change, I'll discuss it here first. Is another contributor already working on this?

That gives maintainers more to work with than simply saying "I'll do it." It also helps other contributors see which work is underway.

Write an issue someone else can follow

A useful issue lets someone who has never seen your environment understand the problem.

Search existing issues and PRs before opening a new one. If the same problem is already being discussed, add your environment differences or reproduction results to that thread.

For a new issue, include the project branch and version, agent client, deployment method, actual behavior, expected behavior, and reproduction steps. If you can identify the affected area, name it: MemoryCore, MemoryProxy, MemoryKnowledge, MemoryPanel, an SDK, or deployment scripts.

Write the steps so someone else can follow them. If the problem only occurs with a particular configuration, explain what differs from a working setup. If you cannot reproduce it consistently, report the conditions you have tried.

If you do not know which module is responsible, describe the use case first. When a template field does not apply to your client, enter "Not applicable" and explain your actual environment rather than forcing it into an OpenClaw-specific field.

Remove API keys, application credentials, and other sensitive information before posting logs or screenshots. Report security vulnerabilities privately to [email protected], following the project guide.

Take a small change from fork to pull request

Suppose you want to improve an integration document and have already agreed on the scope in an issue. The following example uses Git Bash or another Bash environment. For exact development requirements, follow the repository's contributing guide.

Fork the repository on GitHub, clone your fork, and add the original repository as upstream:

# Replace YOUR_GITHUB_USERNAME with your GitHub username.
git clone https://github.com/YOUR_GITHUB_USERNAME/TencentDB-Agent-Memory.git
cd TencentDB-Agent-Memory

git remote add upstream https://github.com/TencentCloud/TencentDB-Agent-Memory.git
git fetch upstream
git switch -c docs/clarify-setup upstream/feat/server_team

Here, origin points to your fork, while upstream points to the original project. Base your working branch on the branch you intend to target, so unrelated development tracks do not get mixed into one PR.

Make and validate the change. For documentation, check commands, paths, parameters, and examples. For code, run the tests described by the affected module. Add tests for new features; for a bug fix, prioritize a regression test that reproduces the problem.

Prepare the environment according to your scope. The main service modules use Node.js 22.16.0 or later. Changes to the Python SDK or relevant migration scripts require Python 3.9 or later. Docker is needed when building images or running the full local service stack. Consult the module documentation for dependencies and startup commands rather than assuming every directory has the same development scripts.

Commit using the project's Conventional Commits format. For example, if you changed INSTALL_CN.md:

git add INSTALL_CN.md
git commit -s -m "docs(docs): clarify setup prerequisites"
git push -u origin docs/clarify-setup

Every commit needs a DCO sign-off. The -s option adds a Signed-off-by line using your current Git identity, so check your configured name and email first. This sign-off is different from a GPG cryptographic signature.

Create a PR on GitHub with the original repository as the base repository, normally feat/server_team as the base branch, and your fork's working branch as the compare branch.

Make the change understandable and verifiable

Before submitting a PR, I would ask: Can someone seeing this change for the first time understand what it solves and how to check it?

The project's PR template asks for a description, related issue, change type, self-test checklist, and additional notes. Filling in the sections is the beginning; the description should provide enough evidence for a reviewer to assess the change.

For a documentation update, explain which prerequisite was missing, what you added, whether you verified the procedure, and which environments remain untested. For changes across modules, identify the primary area, related modules, and interfaces that need coordination.

Report only the validation you actually completed. A successful Linux check does not establish that every operating system works. Editing documentation does not itself verify the underlying code behavior. Clearly stating what you have not checked is more useful than ticking unsupported boxes.

After submission, follow up on CI and review. Feedback may concern compatibility, interface conventions, test coverage, or maintenance costs. Update the change and validation results where appropriate. If you disagree, explain the evidence and tradeoffs so the discussion stays focused on the problem.

The project aims to provide an initial issue response within 24 hours. That is not a promise to resolve the problem or merge a PR in that time. The reviewer accepting a PR communicates the first-review timeline according to its scope. An authorized maintainer or Committer makes the final merge decision.

Keep participating after the first contribution

After completing a small task, you could add tests, help reproduce a related issue, or learn more about other discussions in the same module. Staying with one area is a useful way to build understanding.

TencentDB Agent Memory defines three community roles: Contributor, Reviewer, and Committer. A first meaningful contribution can establish you as a Contributor, and it need not involve code. Reviewer and Committer responsibilities require sustained participation, relevant project understanding, and invitation or explicit authorization from maintainers. They are not titles automatically awarded after a fixed number of PRs.

The project also recognizes contributions. Merged changes from external contributors are credited in the corresponding Release Notes with PR links. First merged PRs and impactful contributions may be featured in community updates. Contributors may have opportunities for exclusive merchandise, mentor matching, and community speaking, subject to the guide and subsequent announcements.

I would treat these opportunities as outcomes of continued collaboration. Open-source work gives you practice in describing problems, controlling scope, explaining technical decisions, and leaving work that another person can continue.

The same responsibility applies when using AI assistance. Tools can help you read code, draft tests, or organize documentation, but you need to understand the submitted change and remain responsible for its quality. Reviewers need a contributor who can explain and verify the work.

If you are ready to begin, open the contribution guide, choose a workflow you can understand, and find a problem you are willing to follow through on. Even without a code change, a solid reproduction record or validation result can help the project move forward.

Project: TencentDB Agent Memory

Community entry point: Contribution and Collaboration Guide #1639

Development and submission requirements: CONTRIBUTING.md