A proposal for management of change

A proposal for management of change

[Thomas Koenig]

 From the discussion, it seems that there is concern about some of the
the technical directions imposed on gcc by the FSF.  If we want to
resolve the current crisis without causing a fatal split within the
gcc community, we need a way at least to address those.

Therefore, a proposal for a procedure for setting guidelines which
may also deviate from the ones

If such a deviation is deemed necessary by somebody, it is handed
to the steering comittee, which puts it to the gcc mailing list
as an officlal RFC. Going through the steering committee is a
step for weeding out suggestions which are obviously frivolous
or trivial.

If, after discussion and possible modification, there is unanimous
or near-unanimous consent, the RFC is approved or rejected.  If
there is significant division, it is put to a vote. Everybody who
is listed in the MAINTAINERS file gets a vote, and the majority
vote is binding if there is a majority of at least n votes (with
n to be discussed).

The steering committee then documents the new guideline.

The whole thing should be restricted to technical matters, and
I would envision this only happening rarely, like once or twice
a year.

Why this rather bureaucratic procedure?  Because it gives a clear
and documented mandate for a change, if it is supported by the
majority of the developers.  If anybody (like the FSF) takes
exception to the change, it would be something to go up against.

Comments?

Re: A proposal for management of change

[Frosku]

On Fri Apr 16, 2021 at 7:37 AM BST, Thomas Koenig via Gcc wrote:
> From the discussion, it seems that there is concern about some of the
> the technical directions imposed on gcc by the FSF. If we want to
> resolve the current crisis without causing a fatal split within the
> gcc community, we need a way at least to address those.
>
> Therefore, a proposal for a procedure for setting guidelines which
> may also deviate from the ones
>
> If such a deviation is deemed necessary by somebody, it is handed
> to the steering comittee, which puts it to the gcc mailing list
> as an officlal RFC. Going through the steering committee is a
> step for weeding out suggestions which are obviously frivolous
> or trivial.
>
> If, after discussion and possible modification, there is unanimous
> or near-unanimous consent, the RFC is approved or rejected. If
> there is significant division, it is put to a vote. Everybody who
> is listed in the MAINTAINERS file gets a vote, and the majority
> vote is binding if there is a majority of at least n votes (with
> n to be discussed).
>
> The steering committee then documents the new guideline.
>
> The whole thing should be restricted to technical matters, and
> I would envision this only happening rarely, like once or twice
> a year.
>
> Why this rather bureaucratic procedure? Because it gives a clear
> and documented mandate for a change, if it is supported by the
> majority of the developers. If anybody (like the FSF) takes
> exception to the change, it would be something to go up against.
>
> Comments?

This seems like a very sensible proposal.

>>= %frosku = { os => 'gnu+linux', editor => 'emacs', coffee => 1 } =<<