Announcing the 'FreeBSD Community Process'

[Benno Rice]

> 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.

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.

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.

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.

Thanks,
	Benno.