Date: Wed, 14 Jun 2017 17:23:54 -0700 From: Benno Rice <benno@jeamland.net> To: Rui Paulo <rpaulo@me.com> Cc: Warner Losh <imp@bsdimp.com>, fcp@freebsd.org, FreeBSD Developers <developers@freebsd.org> Subject: Re: Announcing the 'FreeBSD Community Process' Message-ID: <7E8C8EF6-D73E-4FD3-817F-BADC0527D4B3@jeamland.net> In-Reply-To: <536D30FA-42CF-4F7F-9AE3-70B0822977C3@me.com> References: <539e27d3-4eca-463a-75d4-667d3fec90f6@FreeBSD.org> <f6c69173-bd27-c5a7-7b61-611564fc4d30@FreeBSD.org> <B72BD46B-0CBD-4517-9C90-5AC4A5D61FF3@me.com> <CANCZdfrviwexDJXbA6hK6GiJkdME1N7VZfYUvj1i9WNw-qG-hA@mail.gmail.com> <536D30FA-42CF-4F7F-9AE3-70B0822977C3@me.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Jun 14, 2017, at 15:45, Rui Paulo <rpaulo@me.com> wrote: >=20 > On Jun 14, 2017, at 14:20, Warner Losh <imp@bsdimp.com> wrote: >>=20 >> It was explained at bsdcan the the vote is primarily for "this = repents the general consensus" rather than, this is the direction we = should go. If the fcp doesn't match consensus then it will be voted no. >=20 > That=E2=80=99s what you think will happen, but the FCP doesn=E2=80=99t = say anything about that and the interpretations of the community and = core might be different. > It just seems like a bad model for core to try to interpret = everyone=E2=80=99s feedback and then vote on it. If people provide = feedback and say something like =E2=80=9CAPPROVE=E2=80=9D or =E2=80=9CNEED= S DISCUSSION=E2=80=9D, it will make the process much more transparent. >=20 > The vote should come from the people providing feedback. I see no = reason why core needs to vote on other people=E2=80=99s feedback. I put some thought in to this. I don=E2=80=99t think an ad hoc group comprising just the people = providing feedback works, mainly due to a lack of consistency in the = make-up of the group approving or disapproving. You could have a group = appointed by core (or elected by developers) but then that doesn=E2=80=99t= seem to be too different to just using core itself. Core has = _historically_ not involved itself in technical decisions but there=E2=80=99= s nothing that says they can=E2=80=99t and this model is not the same as = core just making technical decisions without input. I=E2=80=99d be more than happy if you wanted to propose a wording change = that said that core MUST base its decision on the feedback the proposal = has received. In general I=E2=80=99d make the point that core is elected by the = developers. This indicates that the developers have some trust in core = to do the right thing. FCP is designed to help provide structure to = debates over change and help drive them to a resolution. For that to = work there needs to be a consistent group that is distilling the = discussion around the change into a resolution. Even if I weren=E2=80=99t = on core I=E2=80=99d be happy with the concept that core is the right = body for that. The final point I=E2=80=99d make is that the FCP process itself is = designed to malleable. If you feel that core isn=E2=80=99t making the = right decisions, write an FCP that changes the process. If core = doesn=E2=80=99t accept it, vote for a different core and try again. The = process is designed to handle that situation. If you feel there are improvements you can make on FCP 0 now it=E2=80=99s = currently in the feedback state, not the accepted state, for a good = reason. Thanks, Benno.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7E8C8EF6-D73E-4FD3-817F-BADC0527D4B3>