Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115792
Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\))
In-Reply-To: <CADK1yXL=HdA5jF9F09vAgvZYzDpxcuN-1vxudwmZ6BXkjtuPKg@mail.gmail.com>
Date: Tue, 24 Aug 2021 12:00:31 -0700
Cc: PHP internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <741BC7F1-BAF5-4C64-B350-B245FAF88F53@gmail.com>
References: <CADK1yXLZzoOjjNcpZ5ZtV9kSNgw4=SW9G74o26eLdAYV5cDzAQ@mail.gmail.com>
 <alpine.DEB.2.23.453.2108241825130.2773@singlemalt.home.derickrethans.nl>
 <CADK1yXL=HdA5jF9F09vAgvZYzDpxcuN-1vxudwmZ6BXkjtuPKg@mail.gmail.com>
To: Deleu <deleugyn@gmail.com>
Subject: Re: [PHP-DEV] Guidelines for RFC post feature-freeze
From: tobias.nyholm@gmail.com (Tobias Nyholm)


> Tobias Nyholm wrote:
>> then the discussion and the vote should not consider =E2=80=9Cif it =
is too late=E2=80=9D
>> or =E2=80=9Cthis is rushed=E2=80=9D.
>=20
> This is a really bad idea. Previously (but not recently), some of the
> more heated RFC discussions moved from being about the RFC to being
> about what are "right" and "wrong" reasons for voting.
>=20
> That type of discussion very quickly descends into either name
> calling, or people just refusing to take part in discussions.
>=20
> If nothing else, how would you 'prove' that someone has voted for the
> 'wrong reason', and so needs to have their vote discounted?

The issue I have with adding more guidelines for RFCs =E2=80=9Cpost =
feature freeze=E2=80=9D is that it removes decision power from the =
release managers. Ie, one way of reading this proposal is that we =
don=E2=80=99t trust the release managers to decide what to include and =
not to include in a release.=20

To allow the release managers to have this decision power is not a =
=E2=80=9Cviolation of voter rights=E2=80=9D, that is just a silly =
argument.=20


> The proposal is rooted in making it easier for release managers and =
rfc
> authors to refine code changes that may or may not be necessary to
> accomplish a previously approved RFC.

Maybe we should hear what the current and previous release managers =
think? Do they feel like they need more policies around their work?

// Tobias=