Hi, 2015-08-02 17:46 GMT-03:00 Rowan Collins <rowan.coll...@gmail.com>: > On 02/08/2015 21:19, Marcio Almada wrote: >> >> Hi >> >> 2015-08-02 16:52 GMT-03:00 Rowan Collins <rowan.coll...@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
