[riot-notifications] [RIOT-OS/RIOT] CONTRIBUTING/MAINTAINING: Clarify guidelines (#12543)
notifications at github.com
Sun May 24 17:34:11 CEST 2020
@maribu commented on this pull request.
> + There also may be a solution someone has done but just not made a PR, if that
+ is the case first raise an issue or ask on the devel at riot-os.org mailing
I think we might end up receiving >10 emails per day if everyone would ask there before working on a new feature. And I expect at least twice the number of projects are started than actually are completed. I would likely unsubscribe the email list if we start receiving that volume on a daily bases, as I just don't have the time required to read that many emails.
Also, if the effort before opening a PR becomes to big, we end up with less PRs and fewer people contributing.
I think if problems turn up with competing PRs and no one has bad intents, it will be mostly a communication issue. If communication works properly, people should soon figure out if it is best to collaborate (both PRs target similar use cases or the requirements of the use cases do not conflict with each other); or if it is one of the rather rare cases the requirements of the intended use case conflict enough to justify competing solutions. (Examples of this are: GNRC vs lwIP, gcoap vs nanocoap vs libcoap, ...)
> +- If a contributor has opened a PR, the reviewer should attempt to
+ help the author of the contribution to get it to its best shape and
+ according to the RIOT Standard™. If there is disagreement, it’s important
+ to understand the reasons behind and always give technical arguments,
+ pros and cons or snippets.
I think this is uncontroversial. If you want this in soon, you could split this out and keep the discussion focused on the controversial parts.
> +- If the contribution remains below the quality for RIOT then a request should
+ be issued to the contributor asking if a competing PR can be opened.
+ If there is no response after a reasonable amount of time then the competing
+ PR can be open with a reference to the initial contributing PR.
What would we do if someone responds with "no"? Would we really care?
We often have clean up PRs that improve on existing code in RIOT's code base. So far, we have decided based solely on the technical arguments. If a PR indeed improves objectively RIOT's code base and is up to standards, would we ask the original author of the code for permission? (Obviously often the original authors is requested to review, because that author often has the best technical background for doing a review. But we wouldn't stall a PR if there is a rough consensus that it improves RIOT, even if the original author is sees this differently.)
I think we should have the same standard for PRs. If one is technically better and there is no value in having two solutions, IMO we should just merge the better one.
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the notifications