Date: Wed, 14 Jun 2017 19:37:40 -0600 From: Warner Losh <imp@bsdimp.com> To: Benno Rice <benno@jeamland.net> Cc: Rui Paulo <rpaulo@me.com>, fcp@freebsd.org, FreeBSD Developers <developers@freebsd.org> Subject: Re: Announcing the 'FreeBSD Community Process' Message-ID: <CANCZdfpytRBEy_pQSmfLku2wv_gm6TNyB0tG4r4anOzAhZFYrw@mail.gmail.com> In-Reply-To: <7E8C8EF6-D73E-4FD3-817F-BADC0527D4B3@jeamland.net> 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> <7E8C8EF6-D73E-4FD3-817F-BADC0527D4B3@jeamland.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Jun 14, 2017 at 6:23 PM, Benno Rice <benno@jeamland.net> wrote: > > > On Jun 14, 2017, at 15:45, Rui Paulo <rpaulo@me.com> wrote: > > > > On Jun 14, 2017, at 14:20, Warner Losh <imp@bsdimp.com> wrote: > >> > >> 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. I= f > the fcp doesn't match consensus then it will be voted no. > > > > 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 somethi= ng > like =E2=80=9CAPPROVE=E2=80=9D or =E2=80=9CNEEDS DISCUSSION=E2=80=9D, it = will make the process much more > transparent. > > > > 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 providin= g > 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 d= ifferent > to just using core itself. Core has _historically_ not involved itself in > technical decisions but there=E2=80=99s nothing that says they can=E2=80= =99t and this model > is not the same as core just making technical decisions without input. > Core actually *HAS* involved itself in technical decisions. Quite frequently when I was on core. However, it was rarely in the form of "vote on it" (though it did happen), but more often members of core worked to drive discussions and consensus so that core didn't have to vote on things. I have seen it since I was in core too, since the finger prints of it are quire unique if you know what to look for. Many times there were technical disputes that needed mediation to resolve.... I find this as nothing more than writing down what's decided, and core making a note of it. It's got to be better than re-inventing the discussion in a way that polarizes people, pours concrete over the extreme positions and ensures no progress can be made on contentious issues. > 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 receive= d. > I think that's silly, but then again I trust core. If you don't trust core, then you lose no matter what words are here because although MUST is in big shiny caps, "base" is a weasel word that sucks all the meaning out of it since it provides ample wiggle room for mischief. Try to eliminate all weasel words, and you wind up with a policy that's perfectly unambiguous and totally useless. > In general I=E2=80=99d make the point that core is elected by the develop= ers. 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 a= nd > 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 t= he concept that > core is the right body for that. > I'm not on core, and I agree with that. One thing that I help institute, and regret doing so, is the intense secrecy of core. Changing that would help with the trust issue, if members of core were looking for ways to help fix that. Going to a 'default open, but closed where appropriate' model would go a long way towards that, even if that released a lot of super boring stuff that we thankfully have summarized for us. But that's just me.... > The final point I=E2=80=99d make is that the FCP process itself is design= ed 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 reaso= n. > I've read through it, and am confused what the proper place to provide that feedback is, or comment on other feedback... Do you have a good suggestion for where that might be? Warner > Thanks, > Benno.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfpytRBEy_pQSmfLku2wv_gm6TNyB0tG4r4anOzAhZFYrw>