Proposing [constructive] solutions (was: I quit)

> De : Rowan Collins [mailto:rowan.collins@gmail.com] > > Saying "that's enough" isn't even a productive comment. Enough what? > What is it you are asking to happen next? Maybe an initiative to write an RFC about the rules we should follow when writing to the list. People who agree could show their support by a vote. The vote would never end and would just mean 'I agree and will try to follow these rules'. It probably already exists somewhere but refreshing it wouldn't be useless. It's purely symbolic but, once people explicitly show strong support, it becomes an opposable reference. > - There is a lack of expertise at the core level of the code, so > collaboration on each feature is low. RFCs tend to have a single > sponsor, who has to see the whole process through to the end. - One thing we can encourage, while indirect in this case, is writing more comments in code. With PHP 7, Sara's book is almost unusable and nobody will write another one soon. 'UPGRADING' and friends are fine but far from sufficient, especially for newcomers. The only solution I imagine is adding comments in the code. I know it is annoying when you don't have much time, but comments can be improved at any time. They can be written by the feature author, but also by other people, who needed a (too) long time to understand a feature, and write explanations to help followers. As an example, I spent some time understanding the multi-level architecture of str_[i]replace functions and added a lot of comments along with the patch I will propose. Actually, everywhere you spend time understanding what's going on, more comments are needed. That's really important because, today, the code contains almost no comments except function prototypes. That’s ant work and I am far from perfect about comments in my own code, but it can make a difference, especially making the project more attractive for newcomers (and we *need* new blood). - We also can encourage co-authoring RFCs. People are used to work alone but it can change if there's a will. We can also find a set of skilled volunteers agreeing to give their opinion on RFCs before they're announced on the list. That's just an opinion but it can avoid the discussion going nowhere from the beginning. > - The leadership of the language is left to consensus, so that when > consensus cannot be reached, someone has to take on the role of mediator > / chairman / leader for the feature, and try to push through a compromise. I have no democratic solution for this. In the PHP spirit, as Zeev explained, if the RFC process doesn't bring a consensus before the vote, the discussion should stop and the RFC should be modified. Trying to push it to a 2/3 approval while people are fighting is counter-productive. In this regard, IMO (and I told her), Andrea should have withdrawn her RFC much sooner. It would have allowed to take more time for building the next one, and start a new discussion in a more constructive atmosphere. Upcoming feature freeze was probably the reason but the result is that we need to restart everything from scratch in a bitter atmosphere. > - The RFC process traditionally has only one voting phase, with a > Proof-Of-Concept patch completed, and voters expecting few > implementation details to change. So a lot of time has to be committed > to the details of a feature which might be outright rejected. It might > be more efficient if the principle of a change, details such as syntax, > and final implementation, could be considered separate phases. That's the tradition but I think it is quite open for improvements. While we are traditionally using one final vote with multiple options, nothing refrains anyone to organize informative pre-votes during discussion to test the popularity of a feature before he starts writing code, clearly stating that it is not the final vote. This would allow a better information from the community to the RFC author. The interest of such running pre-votes is that they can contain many more options than the final vote and can be started and closed at anytime during discussion. The only requirement is that everyone understands that it in *not* the final vote. Considering the final vote, that's normal to demand a proof of concept patch, as the feature implications are generally not clear (even in author's mind). But the final vote does not require the final PR to be completed. The same for documentation. You just need to prove that your future changes won't create side issues that couldn't be discussed. That's quite understandable and that's a point the scalar type hints RFC was failing because the vote would have ended with a lot of remaining open issues. > - The internals list is quite high-volume, and the same points end up > being raised multiple times, so a feature sponsor has to give the same > counter-point or explanation each time. That's the main issue to the RFC process, IMO, and I'd really favor switching to a more elaborate system. It was often said but it's a pity that a language like PHP, which runs so many high-level collaborative environments, uses such archaic tools for its own purpose. Github provides almost everything we need through issues (subscriptions/notifications, post edition, links to PRs and code blocks, and more), and only lacks an usable voting system. A lot of people are asking for it, but github is not very receptive at user's requests. Maybe we can use it and keep the final vote elsewhere, as the most important is the discussion. If everyone agrees, I can try writing my next RFC this way (a wiki page containing just metainfo and a link to the php-src github issue). The mailing list should be restricted to questions and replies, announcing new RFCs, and general discussion about PHP internals. As soon as an RFC is published, it should evolve in its own space, and people interested in the subject would explicitely subscribe to the discussion. Even the vote should ideally take place only among subscribed people as there is no reason for someone who did not follow the discussion to participate in the final vote (but it will remain open). > Most of these don't have easy solutions, but hopefully they're specific > enough points that we can come up with some concrete ideas on how to > improve things. This post is way too long but that's just ideas. If you think some may be worth starting a separate thread, just tell me. Regards François