Thanks for your interest in contributing to OpenHands! We welcome and appreciate contributions.
Sign in to like and favorite skills
Thanks for your interest in contributing to OpenHands! We welcome and appreciate contributions.
To understand the codebase, please refer to the README in each module:
For benchmarks and evaluation, see the OpenHands/benchmarks repository.
We have a separate doc Development.md that tells you how to set up a development workflow.
There are many ways that you can contribute:
Here are a few ways you can help improve the codebase.
We're always looking to improve the look and feel of the application. If you've got a small fix
for something that's bugging you, feel free to open up a PR that changes the
directory../frontend
If you're looking to make a bigger change, add a new UI element, or significantly alter the style of the application, please open an issue first, or better, join the #dev-ui-ux channel in our Slack to gather consensus from our design team first.
Our main agent is the CodeAct agent. You can see its prompts here.
Changes to these prompts, and to the underlying behavior in Python, can have a huge impact on user experience. You can try modifying the prompts to see how they change the behavior of the agent as you use the app locally, but we will need to do an end-to-end evaluation of any changes here to ensure that the agent is getting better over time.
We use the SWE-bench benchmark to test our agent. You can join the #evaluation channel in Slack to learn more.
You may want to experiment with building new types of agents. You can add an agent to
to help expand the capabilities of OpenHands.openhands/agenthub
The agent needs a place to run code and commands. When you run OpenHands on your laptop, it uses a Docker container to do this by default. But there are other ways of creating a sandbox for the agent.
If you work for a company that provides a cloud-based runtime, you could help us add support for that runtime by implementing the interface specified here.
When you write code, it is also good to write tests. Please navigate to the
folder to see existing
test suites. At the moment, we have these kinds of tests: ./tests
, unit
, and runtime
.
Please refer to the README for each test suite. These tests also run on GitHub's continuous integration to ensure
quality of the project.end-to-end (e2e)
You'll need to fork our repository to send us a Pull Request. You can learn more about how to fork a GitHub repo and open a PR with your changes in this article.
As described here, ideally a valid PR title should begin with one of the following prefixes:
featfixdocsstylerefactorperftestbuildcichorerevertFor example, a PR title could be:
refactor: modify package pathfeat(frontend): xxxx(frontend)You may also check out previous PRs in the PR list.
If your changes are user-facing (e.g. a new feature in the UI, a change in behavior, or a bugfix) please include a short message that we can add to our changelog.
If you notice any bugs or have any feature requests please open them via the issues page. We will triage based on how critical the bug is or how potentially useful the improvement is, discuss, and implement the ones that the community has interest/effort for.
Further, if you see an issue you like, please leave a "thumbs-up" or a comment, which will help us prioritize.
We're generally happy to consider all pull requests with the evaluation process varying based on the type of change:
Small improvements with few downsides are typically reviewed and approved quickly. One thing to check when making changes is to ensure that all continuous integration tests pass, which you can check before getting a review.
We need to be more careful with changes to the core agent, as it is imperative to maintain high quality. These PRs are evaluated based on three key metrics:
If it improves accuracy, efficiency, or both with only a minimal change to code quality, that's great we're happy to merge it in! If there are bigger tradeoffs (e.g. helping efficiency a lot and hurting accuracy a little) we might want to put it behind a feature flag. Either way, please feel free to discuss on github issues or slack, and we will give guidance and preliminary feedback.