Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:104253
MIME-Version: 1.0
References: <03f401d4b96b$18b9dc60$4a2d9520$@php.net> <CA+kxMuTpM=kfLFUtxRY57eWT3N6jx2A9m7MumbSDj=OPuXcdAA@mail.gmail.com>
 <CAJHtznyqZOribu8iyat0i6kQdyyoFEf_jy0GgRy2cH3GWMB4xg@mail.gmail.com>
 <CA+kxMuRdYkACvRFKes9v95MLhR1dwOFwpYUuBFfFARHq5_BUyA@mail.gmail.com> <092c01d4bce3$d8e82e80$8ab88b80$@php.net>
In-Reply-To: <092c01d4bce3$d8e82e80$8ab88b80$@php.net>
Date: Wed, 6 Feb 2019 15:57:45 +0000
Message-ID: <CA+kxMuQpKhqMa9Tv-xbrudoeMtnqE6REJFiX8PaDs89MgNDUZw@mail.gmail.com>
To: Zeev Suraski <zeev@php.net>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] RFC: RFC Workflow & Voting (2019 update)
From: Danack@basereality.com (Dan Ackroyd)

On Mon, 4 Feb 2019 at 23:46, Zeev Suraski <zeev@php.net> wrote:
>
> I've been doing a horrible job at explaining myself if that's what you think I'm trying to do.

As I said before, I think the difficulty has been caused by presenting
a complete set of solutions to multiple problems at once, without
agreement about what the fundamental problems are.

If you want to progress this RFC (or any RFC for that matter) breaking
the whole problem down into individual problems, and then talking
about those is usually more productive and less likely to produce
drama than just introducing a proposed solution.

I'm going to break what has been talked about in this discussion even
further, as I think we're still talking about solutions without
agreeing what the actual problems are.


1. No process for giving vote to userland users.

Although that was proposed in the original voting RFC, I disagree with
this being a big problem that needs solving now. The people who are
voting are also userland users of PHP, and a lot of us use the
libraries/frameworks that would be given a vote.

Even here, the issue isn't necessarily one that would be best solved
with giving people a vote.

I think a better solution would be to make it easier for people
involved with userland libraries/frameworks to give feedback about
RFCs. Something like making a space on the RFCs form for userland
libraries to place their feedback, so that it is easily visible to all
voters, rather than being tucked away in an email thread.

I strongly doubt that if the feedback from multiple userland libraries
was "this is a terrible RFC and will cause us lots of problems", that
those opinions would be ignored.


2. Who can vote needs to be tightened.

While I can agree with that, i'm not sure how big a problem it has
been. I haven't seen many votes where the margin of the decision has
been decided by less than the number of non-core developers voting.

Exactly who can vote is likely to be a big sprawling discussion that's
going to drag on for quite a while.

Although 'anyone with a php.net account' may not be ideal, it has
allowed extension maintainers, documentation writers and other people
who don't meet the 'core contributors' test, but who have otherwise
contributed to PHP to have a vote. I'm pretty sure those people should
still be covered by any new rules.*

Discussing that separately from other topics is likely to be a better
way to proceed.


3. Once given, a vote stays forever, which is probably inappropriate
no matter how the vote was attained.

I think I can agree that people need to be actively contributing to
PHP to be able to continue to vote. Even if someone commits a lot of
code, but then doesn't contribute for five years, why should they
continue to be able to vote?

However that sounds like it is going to need to have a tool built to
track voters registration, which sounds like a decent chunk of work to
build and operate.

Depending on the rules chosen, we might also need an 'appeals' process
for people who either feel that some of their contributions have been
missed, or who have done major contributions that don't fall under the
exact rules.**

cheers
Dan
Ack

* Full disclaimer, I meet the suggested 'git commits to core' to
retain a vote. If I didn't and the work I have done on extensions
didn't count as a good enough contribution, I would find that very
annoying.

** For example, there is a project to move the source for the php
documentation from SVN to git, which is a non-trivial undertaking but
is hard to measure as a contribution in 'lines of code'.