Updated PR template and contributing guidelines

[hubcio]

We've noticed a patterns lately:

• PRs that look fine on the surface but turn into endless review cycles because the author can't really explain or debug their own code,
• Inexperienced devs raising big PRs after only couple of hours of work,
• Low quality of PRs

It's burning maintainers time and will.

So i propose tightening up in #2601:

1. CONTRIBUTING.md - Issue-first, size limits for newcomers, design discussion for risky areas, clearer close policy
2. PR template - Simpler format: why, what changed, did you run it locally, did you use AI

Thoughts?

[slbotbm]

I agree with the sentiment.

That said, currently, pre-commit checks exist only for rust, but the CI defines checks for every language. This means that a contributor needs to run these checks manually, which many of them forget to do. I would propose adding these checks to the pre-commit config as well.

[mmodzelewski]

Agreed, I think prek that we use is pretty flexible. I wonder if it can run some checks based on the changed directory (not everything is always needed).

[lukaszzborek]

Great idea, but only if we can run it for changed foreign clients. I don't think everyone wants to install dotnet sdk to run dotnet format check. Also some fast check in prek and dotnet is not supported (I don't know what they need to support, I'm not very familiar with the prek tool)

[slbotbm]

According to j178/prek#10 , dotnet is not currently supported by prek

[hubcio]

There is no need for it to support dotnet. You can create wrapper scripts that'll call dotnet lints when *.cs files are changed, and it can safely pass if no linter is present.

[spetz]

I do fully agree that in recent times, due to the obvious reasons, the lifecycle of OSS projects has been unfortunately disrupted, thus, clearer, even stricter guidelines would be helpful.

[numinnex]

+1 for the policy, things start to get quite ridiculous with how effortless it became to create an "contribution".

[haubur]

I think this is more than reasonable. As a newbie, I very much like the high effort and positive vibes from all the (core) members. This should not be washed out by energy draining work. So these policies can also protect new joiners who want to make a serious effort.

In addition to the things already mentioned in the PR it might be reasonable to make benchmark tests mandatory.
It's usually asked for, but I think it can be valuable to enforce them.
If one added proper unit tests, integration tests and ran iggy-bench against the contribution there is very high likelihood that the implementation is solid.

[hubcio]

@haubur we can do that, but before I'd like to have a defined standard performance test suite so that we can compare performance using same benchmarks, across many PRs. For now I'll keep it as is and I'll create additional gh issue for this standard suite.

[kparisa]

+1 @hubcio thanks for putting this together. we need to publish and enforce these guidelines sooner than later.