> On 24 Oct 2018, at 14:39, Warner Losh <i...@bsdimp.com> wrote: > > [stuff trimmed] > >> >> The FCP process itself is unclear on this point, >> >> I think this should be clarified. >> >> >> >> It is much more clear on post approval: >> >> Changes after acceptance >> >> >> >> FCPs may need revision after they have been moved into the >> >> accepted state. In such cases, the author SHOULD update the >> >> FCP to reflect the final conclusions. >> >> If the changes are major, the FCP SHOULD be withdrawn >> >> and restarted. >> >> >> > >> > Good point Rod. While common sense suggests that trivial changes during the >> > voting should be allowed for editorial purposes (eg fix grammar mistakes, >> > table rendering etc), it's better to spell that out so there's no >> > confusion. >> > >> > diff --git a/fcp-0000.md b/fcp-0000.md >> > index b4fe0f3..c8cc6f7 100644 >> > --- a/fcp-0000.md >> > +++ b/fcp-0000.md >> > @@ -144,7 +144,10 @@ When the discussion of a change has come to a suitable >> > and acceptable close it >> > SHOULD be updated to the `vote` state. >> > >> > At this time the FreeBSD Core Team will vote on the subject of the FCP. The >> > -result of vote moves the FCP into the `accepted` or `rejected` state. >> > +result of vote moves the FCP into the `accepted` or `rejected` state. The >> > +core team MAY make minor edits to the FCP to correct minor mistakes. Core >> > +MAY return the proposal to the submitter if there are major problems that >> > +need to be addressed. >> >> This is a Bad Idea, because it relies on common understanding of what is >> minor. I was once involved with a standards body that had a procedure for >> so-called clerical errors intended to deal with typos, punctuation etc; this >> worked just fine until somebody claimed that the omission of the word “not” >> in a particular place was clearly a clerical error. > > This documents procedure. It's not law. Trying to read it as law is a > mistake: it's written to be brief and descriptive, not through and > prescriptive. And that's on purpose. Axiom 1 of the bylaws is that you can > trust the core team, which is why the power grant is total and unequivocal: > Core is the governing body of the project. If you can't trust the core team > and need anything more, you've already list. And over the years core's > biggest failing isn't some fleet of black helicopters dispatched to take out > critics or other shenanigans. It's either been not doing enough for the > situation (due to too little time and/or a mistaken impression that they > couldn't do anything), or it's lack of clear communication either between the > different 'hats' and core or between core and the rest of the project. > > Warner
No problem with any of that. If the intent is that “core MAY make unrestricted changes to the FCP and/or MAY return the proposal to the submitter if there are problems that need to be addressed” then say so. -- Bob Bishop t: +44 (0)118 940 1243 r...@gid.co.uk m: +44 (0)783 626 4518 _______________________________________________ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
