Accepting Community PRs?

[RobbieMcKinstry]

Hello!

Is this repository accepting community PRs? If so, please consider adding a CONTRIBUTING.md file or instructions in the README to guide community members toward making fruitful contributions ^.^ . Some questions worth answering:

• What is the quality bar required for a contribution to be accepted? (i.e. does it need to be well tested?)
• Is there a community code of conduct?
• Should community members open an issue to get feedback from maintainers before submitting a PR, to ensure their feature addition is likely to be accepted?

It wouldn't take much to improve the surface area of the library. For example, I'm running an Axum webserver, which requires an async runtime. This library doesn't seem to work in an async context because the blocking client drops a held runtime, which isn't allowed. It would be possible to fix this by using a non-blocking reqwest client.

[joshua-mo-143]

I'm also interested in contributing. PostHog is a great product but an incomplete Rust SDK degrades the experience somewhat.

[djmango]

+1

[joshua-mo-143]

I found out that you can generate an OpenAPI client library using the OpenAPI generator as Posthog has an OpenAPI spec.

For other things, Shuttle has a fork of posthog-rs that includes an async client: https://github.com/shuttle-hq/posthog-rs

[louis030195]

i wish this SDK was more complete too!

atm i just prefer doing raw request myself in https://github.com/louis030195/screen-pipe

[oliverb123]

Hey folks, this repo should be under more active maintenance now. We do accept community PRs, tests are nice for things you can't enforce with the type system (date parsing, string manipulation, etc), but otherwise PR's are acceptable without huge additional test suites. Re: an async client, one has been added and released.

Generally PRs are preferred Issues, if you're willing to put the time into adding code I'm willing to put the time into getting it merged. If you expect a new feature to be large (say, >1000 lines), an issue might be a better way to sketch out the general shape of the feature, so we can get aligned before you put in the work of writing it. A simple "I'd like to be able to do X, here's how I want to add it" is sufficient. Tagging me on issues or reviews is helpful.