Announcing the 'FreeBSD Community Process'

[Warner Losh]

On Wed, Jun 14, 2017 at 6:23 PM, Benno Rice <benno at jeamland.net> wrote:

>
> > On Jun 14, 2017, at 15:45, Rui Paulo <rpaulo at me.com> wrote:
> >
> > On Jun 14, 2017, at 14:20, Warner Losh <imp at 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. If
> the fcp doesn't match consensus then it will be voted no.
> >
> > That’s what you think will happen, but the FCP doesn’t 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’s
> feedback and then vote on it.  If people provide feedback and say something
> like “APPROVE” or “NEEDS DISCUSSION”, 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’s feedback.
>
> I put some thought in to this.
>
> I don’t 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’t seem to be too different
> to just using core itself. Core has _historically_ not involved itself in
> technical decisions but there’s nothing that says they can’t 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’d 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.
>

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’d 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’t on core I’d be happy with the 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’d make is that the FCP process itself is designed to
> malleable. If you feel that core isn’t making the right decisions, write an
> FCP that changes the process. If core doesn’t 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’s
> currently in the feedback state, not the accepted state, for a good reason.
>

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.