Re: [PHP-DEV] Guidelines for RFC post feature-freeze

This is only part of a thread. view whole thread
  115797
August 24, 2021 20:15 tobias.nyholm@gmail.com (Tobias Nyholm)
Hey Marco. 

I know you are not a bad person and Im sure your intention is to bring more clarity and to add something that is helpful. 
And to state something I hope is obvious: I am not accusing you for trying to reduce the role of Release Manager or anything else. 

> I'm interested in understanding how the proposal gives this impression
The fact that you unprompted (as far as I can tell) decided to in detail specify how RMs should make their decision about an RFC is giving me a strong signal that you don’t trust the role of the Release Manager. The timing of your RFC is also unfortunate assuming you don’t want to imply they are doing a poor job as they just got some criticism in a different thread. I may be wrong and the current and previous release managers feel like they really need another policy dictating their work, if so I really hope you worked with a few of them while you drafted this RFC. // Tobias
  115798
August 24, 2021 22:24 deleugyn@gmail.com (Deleu)
On Tue, Aug 24, 2021 at 10:15 PM Tobias Nyholm nyholm@gmail.com>
wrote:

> Hey Marco. > > The fact that you unprompted (as far as I can tell) decided to in detail > specify how RMs should make their decision about an RFC is giving me a > strong signal that you don’t trust the role of the Release Manager. The > timing of your RFC is also unfortunate assuming you don’t want to imply > they are doing a poor job as they just got some criticism in a different > thread. > > I may be wrong and the current and previous release managers feel like > they really need another policy dictating their work, if so I really hope > you worked with a few of them while you drafted this RFC. > > > // Tobias
I have updated the gist to include a Motivation section that attempts to shed a bit more light into what the general idea is. If there is anything in the text of the RFC that validates your perception to the RFC, I would be interested in changing that. As for your perception, I would like to make an attempt to clarify my perspective in the hopes of easing some of these concerns. Timing: I feel like proposing a policy change when it isn't clear why such a proposal is being made is actually worse as it is not clear why such a proposal would be made. I believe timing works in favour of the RFC because people may be more receptive to perceiving that amending the guidelines could have made recent events smoother for people involved. Implying a poor job from Release Managers: As I stated on the Nullable Intersection thread, I don't feel like there was any misconduct or poor handling of the process. In fact, the text I drafted for this RFC simply reinforced everything that was already done: RMs can grant permission for a Refinement RFC and can rescind it. Other release managers would be able to see stated on the RFC that a grant was given. Dictating Release Managers work: The text does not attempt to do that either. It just explicitly empowers Release Managers and instructs RFC Authors how to present a Refinement RFC. Working with Release Managers: I'm a novice in the PHP Project and I don't feel comfortable bothering anybody personally. This thread doesn't even represent the official RFC discussion, it just follows the item 1) of How to Propose a RFC [1]: "Email internals@lists.php.net to measure reaction to your intended proposal." As such, I feel like I'm properly following the guidelines on how to propose an RFC by measuring the reaction of internals about my proposal. Unprompted: As I sadly failed to link on the first email, Nikita has made a comment about whether the process should be a bit more flexible when trying to implement approved RFCs [2]. I saw an opportunity to pick up the work on that and I just did. Part of my motivation is to empower core developers to bring Refinement RFCs whenever they're struggling to land an implementation that suddenly presents challenges that were hidden such as how the Attribute syntax was ambiguous after it had been approved. If I failed to address any of your concerns, I'm happy to try again and I want to reinforce that if you can link any of these concerns you raised to the text of the RFC, I really want to change the text. As an author of a Policy RFC, I want to be absolutely sure that nobody in the future would read the text and feel like the policy is dictating how Release Managers should work. [1] https://wiki.php.net/rfc/howto [2] https://externals.io/message/115700#115753 On Tue, Aug 24, 2021 at 9:30 PM Sara Golemon <pollita@php.net> wrote:
> TL;DR - This RFC sounds like a great idea, assuming appropriately scoped. > > -Sara >
That's wonderful to read! I'm looking forward to refining the scope as necessary. One question I have for experienced release managers is whether clause 11 is good/bad and whether it should mention a specific number of days or leave it open for judgement calls. -- Marco Aurélio Deleu
  115883
August 27, 2021 17:44 Danack@basereality.com (Dan Ackroyd)
Tobias wrote:

> I know you are not a bad person... > > The fact that you unprompted (as far as I can tell) decided to in > detail specify how RMs should make their decision about an RFC is > giving me a strong signal that you don’t trust the role of the Release > Manager. The timing of your RFC is also unfortunate assuming you don’t > want to imply they are doing a poor job as they just got some criticism > in a different thread. > > I may be wrong and the current and previous release managers feel like > they really need another policy dictating their work, if so I really > hope you worked with a few of them while you drafted this RFC.
If you're going to call people names, you may as well do it openly, rather than through passive aggressive phrasing like this. Also, if you could stop describing decisions that you disagree with as "obvious mistakes" when the RFC author was pretty clear about the intention, and the vote passed 30 - 3. Quite a few times you're giving the impression that you think other people are dumb if they can't even see this "obvious mistake".
> And to state something I hope is obvious: I am not accusing you for trying to reduce the role of Release Manager or anything else.
You are projecting here. You're the person who is proposing giving Release Managers new powers to have special RFCs where "vote should not consider “if it is too late” or “this is rushed”."
> To allow the release managers to have this decision power is not a > “violation of voter rights”, that is just a silly argument.
It's a change from what we've had before, and blowing off other people's concerns about putting too much power in the hands of a few people is condescending.
> one way of reading this proposal is that we don’t trust the release managers to decide what to include and not to include in a release.
To be clear, I don't trust release managers to decide that. Though they are all lovely people, not all of them have a deep enough understanding of PHP core to be fully able to evaluate changes. Coincidentally, it is explicitly listed that the Release Manager role does not include deciding what gets shipped - https://wiki.php.net/rfc/releaseprocess#rms_role "RMs Role - But they are not: Decide which features, extension or SAPI get in a release or not" Nicolas Grekas wrote:
> Can you please let me know how that helps?
It helps point out how obtuse you are being. Yeah, everyone gets it, there are quite a few people who commit to Symfony who don't like that the "Pure intersection types" RFC only implemented a pure intersection type and didn't allow a union type with null. But having people from that community turn up, call people names, call things "obvious mistakes" and try to change what feature freeze means e.g.
> but what is "feature freeze" supposed to mean if we aren't allowed to discuss, > alter, or even revert not-yet-released features?!? > anything that is not yet released should be re-discussable until either > beta or RC stage.
One of the hardest things to do in an Open Source project is to say 'no' to someone when they are making a request that isn't completely unreasonable. IMO, it would have been better if the 8.1 RM managers had said no to opening the "Nullable Intersection types" RFC, but I'm also pretty sure they expected you to behave better and not to throw mud around what processes the PHP does or should follow. If you want people who contribute to PHP core to ship 'more complete' features, how about getting Symfony the company (or any other company) to sponsor some of them: https://phpopendocs.com/sponsoring/internals cheers Dan Ack
  115884
August 27, 2021 18:11 tobias.nyholm@gmail.com (Tobias Nyholm)
Hey Dan.

I see that you read what I wrote and intrepid it in the worst possible way. I will try to be more clear and more carefully chose my words in the future. 

I called it an “obvious mistake” because it was clear to me that we missed something. We are not bad people or worse developers because we made a mistake. We (the community) are also not shielded from making mistakes just because we have a voting process. I understand that other people are not consider it to be a mistake. That is fine. I am wrong to call it “obvious”. 

>> one way of reading this proposal is that we don’t trust the release managers to decide what to include and not to include in a release. > > To be clear, I don't trust release managers to decide that. Though > they are all lovely people, not all of them have a deep enough > understanding of PHP core to be fully able to evaluate changes.
I think there are over 1000 people with “voting powers”. I assume you trust a majority of them to have this “deep enough understanding of PHP core”. If you don’t trust the release managers to manage the release, then I suggest you should improve the way we select new release managers.
> One of the hardest things to do in an Open Source project is to say > 'no' to someone when they are making a request that isn't completely > unreasonable. IMO, it would have been better if the 8.1 RM managers > had said no to opening the "Nullable Intersection types" RFC,
Yes, but it does not mean that you *have to* say no. But I do agree with you. The process would have been way better if they said “no". Or if they clearly and unanimously said “yes” which would remove focus on “it feels rushed” and “we can’t because of feature freeze”. This is the the extended power I would like the RMs (as a group) to have. To be clear, Im not suggesting they should veto every RFC. Just changes during feature freeze. Since RMs are experienced open source developers, Im sure they know to ask for help privately whenever they need it. // Tobias
> On 27 Aug 2021, at 10:44, Dan Ackroyd <Danack@basereality.com> wrote: > > Tobias wrote: > >> I know you are not a bad person... >> >> The fact that you unprompted (as far as I can tell) decided to in >> detail specify how RMs should make their decision about an RFC is >> giving me a strong signal that you don’t trust the role of the Release >> Manager. The timing of your RFC is also unfortunate assuming you don’t >> want to imply they are doing a poor job as they just got some criticism >> in a different thread. >> >> I may be wrong and the current and previous release managers feel like >> they really need another policy dictating their work, if so I really >> hope you worked with a few of them while you drafted this RFC. > > If you're going to call people names, you may as well do it openly, > rather than through passive aggressive phrasing like this. > > Also, if you could stop describing decisions that you disagree with as > "obvious mistakes" when the RFC author was pretty clear about the > intention, and the vote passed 30 - 3. > > Quite a few times you're giving the impression that you think other > people are dumb if they can't even see this "obvious mistake". > >> And to state something I hope is obvious: I am not accusing you for trying to reduce the role of Release Manager or anything else. > > You are projecting here. > > You're the person who is proposing giving Release Managers new powers > to have special RFCs where "vote should not consider “if it is too > late” or “this is rushed”." > >> To allow the release managers to have this decision power is not a >> “violation of voter rights”, that is just a silly argument. > > It's a change from what we've had before, and blowing off other > people's concerns about putting too much power in the hands of a few > people is condescending. > >> one way of reading this proposal is that we don’t trust the release managers to decide what to include and not to include in a release. > > To be clear, I don't trust release managers to decide that. Though > they are all lovely people, not all of them have a deep enough > understanding of PHP core to be fully able to evaluate changes. > > Coincidentally, it is explicitly listed that the Release Manager role > does not include deciding what gets shipped - > https://wiki.php.net/rfc/releaseprocess#rms_role > > "RMs Role - But they are not: Decide which features, extension or SAPI > get in a release or not" > > Nicolas Grekas wrote: >> Can you please let me know how that helps? > > It helps point out how obtuse you are being. > > Yeah, everyone gets it, there are quite a few people who commit to > Symfony who don't like that the "Pure intersection types" RFC only > implemented a pure intersection type and didn't allow a union type > with null. > > But having people from that community turn up, call people names, call > things "obvious mistakes" and try to change what feature freeze means > e.g. > >> but what is "feature freeze" supposed to mean if we aren't allowed to discuss, >> alter, or even revert not-yet-released features?!? >> anything that is not yet released should be re-discussable until either >> beta or RC stage. > > One of the hardest things to do in an Open Source project is to say > 'no' to someone when they are making a request that isn't completely > unreasonable. IMO, it would have been better if the 8.1 RM managers > had said no to opening the "Nullable Intersection types" RFC, but I'm > also pretty sure they expected you to behave better and not to throw > mud around what processes the PHP does or should follow. > > If you want people who contribute to PHP core to ship 'more complete' > features, how about getting Symfony the company (or any other company) > to sponsor some of them: https://phpopendocs.com/sponsoring/internals > > cheers > Dan > Ack
  115889
August 28, 2021 04:41 ramsey@php.net (Ben Ramsey)
--PkDRBnhH8nxlnI28tpaHjamVruhgtwe6Q
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

Tobias Nyholm wrote on 8/27/21 13:11:
>>> one way of reading this proposal is that we don=E2=80=99t trust the r= elease managers to decide what to include and not to include in a release=
=2E
>> >> To be clear, I don't trust release managers to decide that. Though >> they are all lovely people, not all of them have a deep enough >> understanding of PHP core to be fully able to evaluate changes. >=20 > If you don=E2=80=99t trust the release managers to manage the release, = then I suggest you should improve the way we select new release managers.=
=20 I'm not speaking for Dan here, but as one of the release managers, I don't think Dan's statement was intended to mean he doesn't trust the release managers to "manage the release." What he said is that he doesn't trust the release managers to decided what to include and not include in a release. A PHP release manager's job is narrowly defined as:
> A release manager's role includes making packaged source code > from the canonical repository available according to their release > schedule.[1]
That's pretty much it. That's our job. Our job is NOT to decide what goes into a release. That's the job of the voters. That said, the release schedule (which is completely within the purview of the release managers' jobs) defines dates for each release, including the feature freeze, and the release managers have the authority to change these dates, if necessary. We did not choose the change the dates in this circumstance because there was no need to change them. There were no issues requiring a change to the release schedule.
>> One of the hardest things to do in an Open Source project is to say >> 'no' to someone when they are making a request that isn't completely >> unreasonable. IMO, it would have been better if the 8.1 RM managers >> had said no to opening the "Nullable Intersection types" RFC, >=20 > Yes, but it does not mean that you *have to* say no. > But I do agree with you. The process would have been way better if they= said =E2=80=9Cno". Or if they clearly and unanimously said =E2=80=9Cyes=E2=
=80=9D which would remove focus on =E2=80=9Cit feels rushed=E2=80=9D and = =E2=80=9Cwe can=E2=80=99t because of feature freeze=E2=80=9D.
> This is the the extended power I would like the RMs (as a group) to hav= e.=20
We already have this power, and we exercised this power in this particular situation, but we are also human, and we made some communication mistakes.
> To be clear, Im not suggesting they should veto every RFC. Just changes= during feature freeze. Since RMs are experienced open source developers,=
Im sure they know to ask for help privately whenever they need it.=20 To be clear, we DO NOT have the power to veto an RFC, and this is not a power the release managers should ever have. Cheers, Ben [1]: https://github.com/php/php-src/blob/master/docs/release-process.md --PkDRBnhH8nxlnI28tpaHjamVruhgtwe6Q--
  115890
August 28, 2021 05:55 jordan.ledoux@gmail.com (Jordan LeDoux)
On Fri, Aug 27, 2021 at 11:11 AM Tobias Nyholm nyholm@gmail.com>
wrote:

> > But I do agree with you. The process would have been way better if they > said “no". Or if they clearly and unanimously said “yes” which would remove > focus on “it feels rushed” and “we can’t because of feature freeze”. > This is the the extended power I would like the RMs (as a group) to have. > > To be clear, Im not suggesting they should veto every RFC. Just changes > during feature freeze. Since RMs are experienced open source developers, Im > sure they know to ask for help privately whenever they need it. > > // Tobias >
I do not believe the reason people felt it was rushed is because of ambiguity from RMs. The reason people felt it was rushed is because: 1. It was a special case of combination types, which voters understood to be a feature targeting 8.2 2. Because it was a feature understood to be targeting 8.2, there was insufficient research into what was technically possible or favorable for general combination types. 3. Because it was a feature understood to be targeting 8.2, it had been specifically excluded from the intersection types RFC. None of those would have been addressed by anything from the RMs, because all of those have to do with the voters' understanding of what the roadmap is and what they had previously voted on. The people who had voted to include intersection types had very specifically been told that they were not nullable, and voted for it anyway, knowing that nullability would come when anticipated support for combination types came. This is my understanding of the situation, in any case. Jordan
  115898
August 30, 2021 15:43 Danack@basereality.com (Dan Ackroyd)
On Fri, 27 Aug 2021 at 19:11, Tobias Nyholm nyholm@gmail.com> wrote:
> Hey Dan. > > I see that you read what I wrote and intrepid it in the worst possible way.
This is also passive aggressive phrasing. You're trying to make me feel bad for pointing out how your phrasing is not conducive to a pleasant productive conversation.
> I called it an “obvious mistake” because it was clear to me that we missed something.
'We' didn't miss it. You might have, but multiple people have explained multiple times that it was a deliberate choice to limit the scope of work for one RFC. If you had written "I consider it a mistake" that leaves room for other people to have a different opinion. But you have kept writing things like "Just because it was intentional, does not make it less of a mistake." which is dismissive of other people's point of view.
> I think there are over 1000 people with “voting powers”. I assume > you trust a majority of them to have this “deep enough understanding of PHP core”.
Well. Most of the time people will only vote if they feel they understand the subject being discussed, and have enough confidence that voting a particular way is the right choice. That's quite different from trying to make someone _have_ to say yes or no. But there is at least one RFC that, in my opinion, there were a lot of people who voted who did not fully understand the technical details, or the implications for on-going maintenance: https://wiki.php.net/rfc/jit
> If you don’t trust the release managers to manage the release,
Ben is right, I didn't say that. I was responding to your sentence which was "what to include and not to include in a release.".
> then I suggest you should improve the way we select new release managers.
'Volunteering' other people to do work is also a passive aggressive way of phrasing things. You're the person who is apparently unhappy with the current process that has been used for over a decade. If you want it changed, you do the work to change it.
> This is the the extended power I would like the RMs (as a group) to have.
That is also volunteering other people for more work. IMO the position of RM is already stressful enough, to the extent that I will never volunteer to be one, as it would cause me to have a nervous breakdown. Making it so that they also have to be arbiters of which post feature freeze RFCs are 'valid' or not would be an extra, and stressful, burden for them to carry. Pierre Joye php@gmail.com> wrote: Well, as the mailing rules have been linked, I might as well quote this bit: "Do not top post. Place your answer underneath anyone you wish to quote and remove any previous comment that is not relevant to your post." sincerely Dan Ack
  115899
August 30, 2021 18:56 tobias.nyholm@gmail.com (Tobias Nyholm)
Hey Dan. 

I do appriciate to hear your point of view. This thread is now very off-topic. With respect to Marco and other people that wants to discuss guidelines for the RFCs and the role of RMs, I will not answer you anymore. 

Feel free to reach out to me privately or in a new thread.

// Tobias