Working style in this repo

[jenshenneberg]

After having a look at the changes between the last two releases, here I have 2 suggestions:

• Please consider using PR's to make changes as opposed to committing directly to the main branch. It's best practice, and would give the community a chance to comment on upcoming changes
• Please consider improving the test strategy. I'm concerned about updating to the latest version of the SDK, when I see changes as big as those above without a single test to cover the changes

Just my 2 cents. 🙂

[tore-statsig]

Thanks for the feedback. The way we tend to develop is a bit different - even when you've put up pull requests on this public repository, it goes through a separate process:

• we maintain a public/private pair of repositories for each sdk. When we make changes, we make them on the private sdk repository. When we publish, we sync all changes in that version to the public sdk
• we have a centralized test harness that runs tests ensuring consistency across sdks. Most of our tests end up in there - you can see the KONG action on all pull requests and release commits https://github.com/statsig-io/dotnet-sdk/actions/workflows/kong.yml. I wish we could show all of those test cases but kong is not open source (maybe one day). We do some unit testing in each language and repository, but won't guarantee that for any given change

Most of this process has actually been established given the lack of community involvement on our sdks. Would you actually look at and review PRs to this repository, or is that more aspirational?

[jenshenneberg]

Thanks for the detailed response @tore-statsig. I think Statsig is a great product, and hope the community will grow. While I cannot say I would review any and all PR's, the work done here has my interest. Any transparency about the work done and features coming up would be greatly appreciated.

[tore-statsig]

Gotcha. At the moment I dont anticipate us changing that working style (at this point even our release tooling is built around this workflow, so it would be heavier lift), but we are open to changing our process (especially to make community involvement more seamless). Thanks again