Hi,
Le 2025-02-07 13:13, Elliotte Rusty Harold a écrit :
As long as there's a PR and a history, we don't gain a lot by using
more than one. There can be more than one if more people want to
review, but it's not required.
Also if the reviewer thinks a second (or third...) review or advice
w
>> We're already struggling at maintaining full Maven scope, for the
few of us
who try. I seriously fear adding more constraints will make our life even
harder than it is now.
Knowing that the number is very low, I totally understand this.
For me personally as a new one, written policies (how str
Thanks for posting. I was thinking about posting something myself.
With respect to number of approvals specifically, the answer is 1.
This is what's been used in every project and company I've ever worked
with that does code reviews. As long as there's a PR and a history, we
don't gain a lot by us
let's step back one minute:
1. what problem are you trying to solve?
2. please take time to understand the larger bad implications I'm trying to
avoid
We're already struggling at maintaining full Maven scope, for the few of us
who try. I seriously fear adding more constraints will make our lif
Le jeudi 6 février 2025, 20:51:09 CET Matthias Bünger a écrit :
> Hi all,
> I would like to bring the (as of my understanding) not yet finished
> discussion about the commit/review policy with Github from a _merged_ GH
> PR [1] to the mailing list, as suggest by Hervé:
>
> As a short summuary:
> *
Hi all,
I would like to bring the (as of my understanding) not yet finished
discussion about the commit/review policy with Github from a _merged_ GH
PR [1] to the mailing list, as suggest by Hervé:
As a short summuary:
* In times of SVN there was "Commit Then Review" (CTR) policy
* Since Github,
