Built by the people who use it.

Most of what keeps this library good is not code. It is people telling us what broke, what confused them, and what they wish it did.

Below, roughly in order of how much setup they need — the first two cost nothing but attention.

1. Tell us what you found

An issue is not a complaint, it is data. We cannot fix what nobody reports, and we cannot prioritise what nobody asks for.

A good one takes ten minutes: what you ran, what you expected, what happened, and your versions from rfbrowser --version. A short reproduction beats a long description every time. Feature ideas are just as welcome — say what you are trying to achieve rather than what API you want, and we can usually find something better together.

2. Answer someone

You do not need to be an expert. If you solved something last month, you know more about it than the person hitting it today.

Every answered question in Slack or the forum is a question the core team does not have to answer — and, if you write it in the forum, one that answers itself for everyone who searches later. This is the single highest-leverage thing a happy user can do.

3. Improve the documentation

You are reading it. If a page is wrong, out of date, or explains the easy part and skips the hard one, that is a bug, and it is one you are unusually well placed to fix — you just hit it.

Docs changes need no development environment. The site's pages are Markdown in the repository, and typo-sized fixes are perfectly welcome pull requests. So are issues that just say "this paragraph made no sense to me".

4. Test main before it becomes a release

We do not ship release candidates, so there is nothing to wait for. Instead, every commit to main that passes CI builds an installable wheel, and you can have it within a minute of a fix landing.

Running it against your own suite for ten minutes is worth more than any amount of testing we can do ourselves, because your suite does things ours never thought of. It is also the only way a regression gets caught before it is in a release rather than after.

Take the wheel from the latest green Continuous integration run on main — Actions → the run → Artifacts → rfbrowser-wheel — then, in a throwaway virtual environment rather than the one you work in:

pip install --force-reinstall robotframework_browser-*-py3-none-any.whlrfbrowser clean-noderfbrowser init

Tell us either way. "Ran our 400 tests against main, nothing broke" is genuinely useful information, and it is the report we get least often.

5. Build a plugin, and publish it

Not everything belongs in the library. Browser has a plugin API and a JavaScript extension mechanism precisely so that your idea does not have to wait for our review — you can build it, publish it, and own it.

And then tell people it exists, which is the step everyone skips. robotframework-browser-extensions collects the ones that work — accessibility checks with axe-core, visual comparison, network throttling, request mocking, element highlighting. It is a monorepo, not a registry: if yours works, open a pull request and it goes in.

That is also the strongest possible argument for bringing a feature into the library itself. Something people are already installing has proven demand behind it, and several features arrived exactly that way.

6. Send a pull request

And yes — code. Bug fixes, keywords, tests, type hints.

Start by opening an issue or asking in Slack, unless the change is small. Not gatekeeping: it is so nobody spends a weekend on something that turns out to conflict with a change already in flight. The contribution guide covers the development environment, the test suites and the conventions.