On 16 June 2024 03:00:39 BST, "Marco Aurélio Deleu" <deleu...@gmail.com> 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]

Reply via email to