Declare that simple PRs for core will be reviewed

[kyukhin]

We need to state, that core team will review simple patches for core Tarantool.
What is simple is the matter of common sense.
Example:

• Simple: update error message in Lua built-in
• Not-simple: fix logic in VInyl compaction strategy to increase performance

[tsafin]

i.e. here https://www.tarantool.io/en/doc/2.5/dev_guide/developer_guidelines/#how-to-submit-a-patch-for-review

we state that:

We don’t accept GitHub pull requests. Instead, all patches should be sent as plain-text messages to tarantool-patches@dev.tarantool.org. Please subscribe to our mailing list at https://lists.tarantool.org/mailman/listinfo/tarantool-patches to ensure that your messages are added to the archive.

instead we should reword it something like:

Tarantool core team uses patches which to be sent as plain-text messages to tarantool-patches@dev.tarantool.org. Please subscribe to our mailing list at https://lists.tarantool.org/mailman/listinfo/tarantool-patches to ensure that your messages are added to the archive. External contribution via pull-requests is acceptible for simple patches, but mailing list is more preferable.

Somethign like that? @kyukhin

[Totktonada]

I would ever say that PR is preferable, when you don't know for sure who should review your patch. So for almost all external contributions.

Personally I mostly ignore patches, where I'm not in CC (it is not possible to track everything).

[kyukhin]

@lenkis I guess this is not raw idea.

[tsafin]

I would ever say that PR is preferable, when you don't know for sure who should review your patch. So for almost all external contributions.

BTW, I assume that before we would go with this policy publicly, and the stream of new PRs would start to flood us (:) ) it would be a good idea to populate .GITHUB/CODEOWNERS file with the list of initial reviewers for all subsystems, to start review process faster and smoother, while external contributor still might have no idea whom to ask for review.

[Totktonada]

I would ever say that PR is preferable, when you don't know for sure who should review your patch. So for almost all external contributions.

BTW, I assume that before we would go with this policy publicly, and the stream of new PRs would start to flood us (:) ) it would be a good idea to populate .GITHUB/CODEOWNERS file with the list of initial reviewers for all subsystems, to start review process faster and smoother, while external contributor still might have no idea whom to ask for review.

It is not a blocker and can be created asynchronously. We should just elect someone to route incoming PRs. @kyukhin would be ideal balancer, because he knows everything core team members load.