Good first issue

[Justin Hernandez Tovalin]

Hello everyone!

I was wondering what is a good first issue to tackle, I look forward to contributing.

[Nadav Har'El]

On Tue, Jan 27, 2026 at 10:11 AM Justin Hernandez Tovalin <jtova...@gmail.com> wrote:

Hello everyone!

I was wondering what is a good first issue to tackle, I look forward to contributing.

Hi,

 

I don't have specific issues to recommend, but I can suggest a few guidelines:

1. If you're not already a Seastar user, please start with that: Learn to use Seastar, or advance your usage of Seastar if you already have a bit of experience with it.
   It's hard to appreciate how to improve the project without being familiar with it first.
2. While you're learning to use Seastar (or improving your skills of using it), you're likely to encounter things you wished were easier to better: Maybe documentation about something was missing or unclear? Maybe a specific function or class was inconvenient to use or hard to learn? Maybe a specific feature you were looking for is missing? This would make a good first issue, and be a good example of "scratching your own itch", a common advice to Open Source contributors.
3. You can browsing the Seastar issue tracker looking for interesting issues, be cautious of "traps" - issues that look very simple but are already years old and nobody did them. Some of these are in fact good ideas that just nobody bothered to implement. But other issues are just "bad" ideas - ideas which nobody implemented because nobody really wanted to. In general, don't take any issue in the bug tracker for granted: Before working on any issue, think for yourself (or seek advice) if you really believe this is a good idea that will improve Seastar and that people would want to use. Would you want to use that new feature or fix, yourself?

Nadav.

[Avi Kivity]

Agree with Nadav above.

An area that can use help is improving the coroutine tooling in include/seastar/coroutine/*.hh. It requires experience with Seastar though - by encountering real-life problems with the existing coroutine support, you find what is missing.

For example, seeing some conversions[1] from continuations to coroutines, we saw that a then::finally equivalent in coroutines would be helpful. This is also how coroutine::try_future came to be.

 

[1] https://github.com/scylladb/scylladb/pull/28375#discussion_r2731365738