Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:87549
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.160.179 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <55BE81BB.2060501@gmail.com>
References: <CAGbiJu-No6nmVt6O05e6oiEJ1jBD-T2fXxLJSMpksf2CE_9HJw@mail.gmail.com>
 <CAOsHV+v7Rwg=DEhtpqc3XzwDqw1Q7aX3_Mvu8FUZhVLeM77jHA@mail.gmail.com>
 <CAGbiJu9_10HU2xCr=rUp72hxPgyvXxVf42s67W_4WorNCANpLA@mail.gmail.com>
 <55BE74F1.3030006@gmail.com> <CAOsHV+ufQv+8BUhoRBD2ihoOaF3mZ0F2nLfBogxa1AV9=HGhYQ@mail.gmail.com>
 <55BE81BB.2060501@gmail.com>
Date: Sun, 2 Aug 2015 19:35:38 -0300
Message-ID: <CAOsHV+tvQn0MhcMHchXcJ-YuV9a+iBFPZ5Mk3_tX3r0mvPPRtA@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] Move internals discussion to a better medium
From: marcio.web2@gmail.com (Marcio Almada)

Hi,

2015-08-02 17:46 GMT-03:00 Rowan Collins <rowan.collins@gmail.com>:
> On 02/08/2015 21:19, Marcio Almada wrote:
>>
>> Hi
>>
>> 2015-08-02 16:52 GMT-03:00 Rowan Collins <rowan.collins@gmail.com>:
>>>
>>> On 02/08/2015 20:10, Marcio Almada wrote:
>>>>
>>>> As you pointed github issues, it's worth noting that Rust internals
>>>> already use github to manage RFCs:
>>>>
>>>> https://github.com/rust-lang/rfcs/pulls?q=is%3Aopen+is%3Apr+label%3AT-lang
>>>
>>>
>>> That's interesting. Do you have a link to any documentation on the
>>> process
>>> they use?
>>
>> You can see the process outlined here
>> https://github.com/rust-lang/rfcs#what-the-process-is.
>>
>>> For instance, how does the RFC gain final approval / rejection?
>>
>> The biggest difference regarding "approval" is that we express
>> "consensus" by having a vote with 2/3 majority (voting makes sense
>> here because consensus by discussion rarely happens anyway).
>>
>> On their side, they usually don't have a voting phase like we do, the
>> "consensus" is built rationally during the discussion phases. See the
>> list of RFCs in final phase
>>
>> https://github.com/rust-lang/rfcs/pulls?q=is%3Aopen+is%3Apr+label%3Afinal-comment-period,
>> as an example.
>
>
> Ah, interesting, thanks. :)
>
> Actually, skimming that documentation, the key difference is not that they
> magically attain consensus 100% of the time, but that they have a nominated
> "core team" who make the final decision (via separate channels, based on
> previous discussion), though all the links to who they actually are appear
> to be dead links.
>

Yes, that's supposed to happen in the "final-comment-period".

They do have a higher ratio of consensus though. But that's because
the language is still fresh, you have less technical debt, less BC
break issues to overcome, less design issues to fix (the language was
planned a lot) and other factors that might not be fruitful to bring
up here now.

Anyway, even with all the contextual differences, the useful lesson I
can take is that they are trying to find a way to get closer to their
community by not simply giving transparency, in a sub optimal way, and
then making claims like "And I'm not sure Whether I want someone
messing arround with the language that powers 80% of the WorldWideWeb
who isn't able to get his tools set up properly" or "just download a
newsreader and store the mails on your own database for further
research.".

They bothered to have transparency but also to wrap it in a more
appealing package. There are different generations of people and the
highly skilled ones that were born 40 years ago are not the same as
the ones born ~20 years ago and volunteering contributing today,
technology change.

This is their email announce the end of their mailing list back in
2015 https://mail.mozilla.org/pipermail/rust-dev/2015-January/011558.html

I'm not saying that we should do exactly the same thing. PHP is not
Rust. Rust is not PHP. But at least we could stop pretending our
process shouldn't be improved because the walls it offers supposedly
act as a filter for the one "who isn't able to get his tools set up
properly". This only shows a deep kind of ignorance on how FOOS works!

> Interestingly, they also currently have an open RFC about scaling their
> governance, including the RFC process itself:
> https://github.com/aturon/rfcs/blob/rust-governance/text/0000-rust-governance.md

I missed this one. This is really cool, thanks for pointing it out.

> Regards,
>
> --
> Rowan Collins


Thanks,
Marcio