Hi Francois, Between my day job and my local user group meetup, I haven't had as much time as I'd like to read and respond to this. You've got some great suggestions here, though, so I'm going to rush through and add some thoughts before I go to bed.
On 16 February 2015 at 15:31, François Laupretre <franc...@php.net> wrote: > > De : Rowan Collins [mailto:rowan.coll...@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. > I think this would work best if it focused on positive statements that everyone should do more - the risk with listing bad things is people can start throwing them at each other as yet more noise, further distracting from the real aim of the conversation. A regular reminder could perhaps be useful; I've thought before about an FAQ for the list, posted every month as was (I believe) traditional on Usenet. A section of that could include succinct reminders of the list's rules, as currently set out in the README file (sorry, I don't have the link to hand). > > - 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). > This is a great suggestion, and one even I could have a go at - I don't really know enough of the core to suggest changes, but occasionally spend time reading it and trying to learn. If I sent in a Pull Request with nothing but comments, someone might even correct my understanding by improving the content, and it would be a double win. - We also can encourage co-authoring RFCs. People are used to work alone > but it can change if there's a will. Agreed. > 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. I think this happens a bit behind the scenes - things have sometimes been talked over on IRC or something first. But perhaps it needs to be more visibly summarised - start the process with a summary of points already raised, and, importantly, acted on. > > - 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. The problem lies in detecting/defining the consensus before the vote takes place. Some say the typehint RFC should not have been voted on in its current form due to lack of consensus, some that it should have been voted on in an earlier form, which Andrea felt lacked consensus. So we don't even have a consensus on how to spot a consensus. I don't know how to get out of that Catch-22. > > - 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. I think the current RFC template encourages the votes to happen in one go, as does the index by status. Perhaps to encourage multiple votes (and collaboration), we could come up with additional headings for the drafting stages. > 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. I think if there was more precedent for voting during refinement of the feature, the scalar typehints vote wouldn't have been labeled "final" (indeed, that label is only implied and assumed because there aren't any non-final votes). An alternative, sort of coming back to the idea of multiple authorship, would be to have "amendments", as found in parliamentary procedures. So that a series of short votes, proposed by different people, could refine the text of the RFC, which would then be voted on as a spec. I'm not sure how well this would work, but thought I'd mention it in case someone wants to ponder it further. > > - 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). I've not used github enough to comment on whether it's suitable, but agree that it would be worth evaluating new tools. I think we need something that ties the discussion closer to the document, and separates sub-topics more readily than most email clients (GMail is particularly awful for navigating busy threads). On the other hand, I think we should use the wiki more as a wiki - right now, it's a document repository running on wiki software, with rarely more than 2 editors touching a page, particularly if it's an RFC. What if we allowed absolutely anyone to edit draft RFCs, in the spirit of the original Wiki? People could add "thread mode" sections on contentious issues, then refactor them into summaries of the main points, either reflecting consensus, or leading to an interim vote. Or at the least radical - remove the "author" and "version history" from the templates; those are document change control conventions, not collaborative editing ones. Instead, something like "primary sponsors" and, if really necessary, "major milestones". > 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). That's an interesting way of looking at it, but there'd need to be some way of the discussion on these "breakout forums" making its way back to the main list in summary form, without it being yet another duty of the RFC sponsor. E.g. I'm not massively interested in DbC, but wouldn't want the whole thing to be discussed off-list, and land with a whole mass of dependencies and syntax extensions. Admittedly, this already happens if I don't skim-read the relevant thread, but it would be nice if it was easier to jump in, not harder. > > 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. Again, thanks for the ideas, and I'm sure I'll have more to say on this as and when I get time. Regards, -- Rowan Collins [IMSoP]
