On 16 June 2024 03:00:39 BST, "Marco Aurélio Deleu" <[email protected]> wrote:
>If you appoint a different jury to try a 20 year old case, the decision of the previous jury
>doesn't have any more weight than any other evidence on its own.
You missed the point of the analogy. The point is that that would only happen if you have some
specific reason why the case needs to be reopened.
I'm not saying nobody is allowed to talk about this. I'm just saying, let's start by
looking at the old discussion, and discuss *specifically* what might have changed, rather than
waving our hands and saying "10 years is a long time, so no opinion from that long ago can
possibly be valid".
>You may have core developers that voted no due to maintenance burden, but if said maintainer is
>no longer active and new maintainers don't mind it, it's a moot argument because people
>changed.
The maintenance burden argument is actually a good example of *not* being about individuals. The
argument is not "I don't want to maintain it", it's "we shouldn't
burden future maintainers with this".
>You may have no votes casted because at the time PHP technical debt couldn't cope with such
>a change, which maybe isn't relevant anymore because the project evolved.
This, on the other hand, is a good example of one where we don't need to guess. Look at the
archives - were people concerned about the implementation? If so, pointing out that the
implementation would now be simpler would absolutely be a reason to bring it back to discussion.
>You may have community leaders voting no because they inherently disagree with the concept but
>if they have moved on to other endeavors and current PHP community members like the concept, then
>society changes play a vital role in a different outcome.
Again, let's stop talking in the abstract, and look at this specific case. Can you point to
changes in the usage of PHP that make this feature more likely to see wide use or acceptance? Do you
think the community at large, who we are trying to represent here, is more or less likely to write a
purely static class in 2024 than in 2014?
All I'm asking is that if we are going to revisit features we previously rejected, we start
with "here's why I think the arguments for and against this feature have changed",
rather than "I don't like the old result, I demand a new vote".
Regards,
Rowan Tommins
[IMSoP]