Help Wanted

[emilk]

Are you looking to help out on the egui project? Then this is a good place to start!

There are a few things you can help out with:

• Answer questions on Discussions
• Contribute code
• Review & discuss existing issues
• Review Pull Requests

First, make sure you read CONTRIBUTING.md.

Contributing code

You can browse existing issues. A lot of them are unfortunately uncategorized, but I've tried adding "good first issue" and "help wanted" on some of them, but of course, I actually want help with all of them 😆

• Issues with the "good first issue" label
• Issues with the "help wanted" label

I use Mac for all my work, so sometimes the Linux and Windows integrations for eframe suffer. Therefore I would appreciate help with that!

• Linux issues
• Windows issues

If you are good at web programming, there are plenty of issues related to the eframe web integration.

There is a milestone with issues that should be fixed before the next release - any help with these issues would be most welcome! https://github.com/emilk/egui/milestone/3

---

Some cherry-picked issues in no particular order:

• Modal dialogs #686
• CSS-like styling #3284
• Panic when zooming out a plot too far #3462
• Tracking issue: Misc improvements to multi-viewports #3556
• Tracking issue: improve Key input #3653
• Window ignoring resize request #3668
• WebGPU build broken #3675
• IME-related issues (text input for e.g. korean)
• Windows and Linux specific eframe/winit integration issues for showing a custom window frame

[samitbasu]

Hi @emilk - thanks for making UI's fun again! On the PR reviews, a couple of questions:

• Can anyone review PRs? Or do they need to belong to the project somehow?
• What happens with PRs that contain API breaking changes (e.g., something that would cause egui_extras to break its API for example.

Also, would it help you if more functionality was broken out of the egui repo (like egui_plot)? Would that allowed for a more distributed support model?

[emilk]

Great questions!

Anyone is welcome to help review PRs, in order to provide feedback and help the PR author. Of course, someone with merge rights will still have the final say (most likely me), but the more eyes on a PR, the better it usually ends up!

Breaking changes are usually fine, but should be documented in the PR description. Of course, if they can be avoided without creating to much hassle, that's often better. Also, using #[deprecated] on removed stuff is encouraged.

Breaking out crates from the monorepo would be nice, but I like having egui and eframe in the same mono-repo, as it makes for much easier testing and iteration.

egui_plot should probably be moved to its own repository though. If anyone would like to take the lead on that I'd be very happy. I'd rather not be the maintainer of egui_plot (I've only written a very small fraction of it).

[nabby27]

Have you considered using a rewards system to encourage developers to contribute to egui? I recently released my new project Opire which does just this.

With Opire not only code owners can create rewards, rewards can be created by anyone (and can be accumulated for the same issue). This allows people to contribute not only with their knowledge and time but also with money. Additionally, the organization receives a percentage if the rewards are created by people outside the organization.

You can see the documentation at docs.opire.dev. If you have questions or want more information, you can contact me 👍