> On Mar 19, 2020, at 6:57 AM, Dan Ackroyd <dan...@basereality.com> wrote: > > Mark Randall wrote: >> >> it should be up to the community to decide if people are trying to >> deliberately flout the spirit of that requirement and take action >> accordingly. > > This type of argument leads us on a path to personal attacks. > > Optionally having some space to record people's reasons for voting > either way might be useful. Requiring people to justify their reasons > is going to lead to massive non-productive arguments, or even people > being harassed for voting 'wrong'.
Since I started this thread, please let me explain what I was envisioning. I was envisioning that the list of reasons would be displayed *separately* from the voting results. I was not envision displaying any visible linkage between voters and who gave what reason. I was simply envisioning that the RFC page — for posterity — would just list the reasons and the number of people who selected that reason for their vote. The reasons could be multi-select, so it would be effectively impossible to guess who gave what reasons, unless someone used the same words in an email exchange at which point they already made their views public. So I envisioned the proposal as a this way specifically to avoid setting up people for personal attacks. To Mark's point, *if* the community sees that there are a lot of nonsense reasons — by which I mean real nonsense like "Because I don't like Mondays" — then people in the community can comment on it and make a generic plea to whomever is giving nonsense reasons anonymously to please stop. Since the goal of capturing these reasons is to capture legitimate history for the benefit of PHP and all who may contribute to it in the future, the request could be "Stop being a a jerk and instead please help the community." Said a different way, I saw this as a way each person voting could help the collective community improve over time and NOT as a way for individuals to be put into any position of having to _justify_ their reasons, hence the anonymity. If I may, please let me share this video which really captures the essence of how I am hoping everyone will view this, as a way to make things slightly better for everyone wanting to contribute to the PHP community and not as any kind of draconian imposition on any individual's rights: https://www.youtube.com/watch?v=BdL91IMl7gc > And I agree with Levi, voting "no" should not require any more effort > than voting "yes". > > This thread has focused on people voting no. That is my fault for emphasizing "no." I emphasized "no" votes because they inevitably result in the topic resurfacing in the future, often again and again. For a successful RFC people do not constantly ask for the feature again and again, for obvious reasons. OTOH, what about declined RFCs? Having people's reasons for "yes" would be as helpful for future contributors as having people's reasons for "no." So I agree, there should not be a difference in effort required between "yes" or "no." > Although I disagree with some decisions people make, I can't see a > large problem of RFCs that have been declined without reasonable > reasons. To be clear, the goal of my straw man proposal was *not* to allow seconding guessing or challenging of decisions made. The goal was to capture the decisions concisely in a single location for an RFC so that people in the future will have visibility into those collective reasons. > If anything, the problem is the other way round, with people who are > not core maintainers, voting yes on things that they can't fully comprehend, > and won't be the ones doing the maintenance work for the RFC. Look at it this way. Consider you are a core maintainer and you feel strongly that many people asking for things don't fully comprehend the ramifications? For you being able to highlight a concise reason you voted "no" on an RFC that future readers will almost certainly see — vs. just commenting on the mailing list which requires a motivated person to find to — will allow you to point people in the future who ask for the same thing (yet again) to the reasons why it was voted down. And that list will include your reasons as well as others. Thus *hopefully* pointing people to the previously decided list of reasons will nip a potentially long, potentially contentious and potentially draining negative email thread in the bud because — for that feature request — it is already known for pretty damn certain that it simply won't happen in PHP. Given the above, I think the people who vote "no" because they really do not want to ever see a proposal pass would *want* to document their reasons in hopes it would stop people in the future from trying to re-litigate the feature. Why do I personally care about this? Because I want to request things in PHP, but I know that doing so successfully requires a herculean effort, and I do not want to commit that time and effort to something that I know has already been decided against by those with a vote for reasons that are insurmountable. > But I don't think asking people to prove that they've fully understood an > RFC is a useful thing to do. I complete agree. What I envisioned was to capture the reasons for the benefit of future contributors and not to provide a mechanism for passing judgements on those reasons or provide a mechanism for retaliation against voters who make a decision that someone else does not like. -Mike P.S. I am working on a critical project with a deadline in late April but after that I hope to try to create an update to the wiki that would let people see how this feature could work. (I have been looking for a way to contribute since I can't currently write C code for PHP core.) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
