So, recently there was some discussion about RFCs that have passed despite there being some strong objections to them.
I think there is a fundamental problem that could be addressed here, in that the arguments 'for' an RFC have much higher visibility than the arguments 'against' an RFC.
The RFC page, which presents the arguments for an RFC, is a link that is emailed round and can be linked to from other sites.
The arguments against an RFC are contained only within an internals email thread. Not only is it much more difficult for people to discover these, as there are part of an email thread they might not be written as concisely and as clearly as they could be.
That sounds like an uneven balance of power which tips the balance towards RFCs passing.
I think we could fix this problem by doing something similar to the following:
When someone creates an RFC, near the top of that page they should create a link to a separate page that will contain negative feedback.
People other that the RFC author are free to put whatever negative feedback think is appropriate on that 'negative feedback' page.
In the (hopefull) rare cases where the people providing negative feedback can't agree on how that page should be formatted, they may create a new negative feedback page and also put a link to it on the actual RFC page, next to the other 'negative feedback' link.
To indicate agreement with any negative feedback, people are free to put their own name (not other peoples names) as a signature after the relevant 'negative feedback' link.
Changing the process to add more visibility to negative feedback with something like the above wouldn't add much burden to the RFC process, and could improve the outcomes in some cases.
Putting the negative feedback on the same page as the RFC would have problems with multiple people editing one document and possibly not agreeing on the formatting.
It could also have problems in making the RFC harder to read, if for example someone decides to write 20,000 words on why an RFC is bad.
If people similar to the people who were kicked off the internals list for being too negative want to write some negative feedback, they're free to do that, and then other people free to not put much value on that.
If people who have more weight in the community are giving feedback, and they all object strongly enough to sign their name, then it behooves everyone to read that feedback.
So we apparently already have a rule that says:
https://wiki.php.net/rfc/howto
Listen to the feedback, and try to answer/resolve all questions. Update your RFC to document all the issues and discussions. Cover both the positive and negative arguments. Put the RFC URL into all your replies.
I think one of the reasons no-one is doing that is that it's just too much work.
It's also just not possible to summarise some of the arguments in a neutral way, and instead if the RFC author attempts to summarise the negative arguments, it would provoke heated arguments.
Changing the responsibility of documenting the negative feedback from the RFC author to people saying that negative feedback, would mean:
- it's more likely to be done.
- it doesn't add to the work needed to be done by an RFC author.
- it avoids heated debate about whether some feedback is relevant or not.
Any thoughts before I spend the time to write this as an RFC?
cheers Dan
(Note: this is only my brain dump after one reading! And, I'm slightly groggy right now; apologies if incoherent.)
I don't think that a meta-discussion wiki page for each RFC is a good way of going about this, particularly if that page is only concerned with documenting "nay" arguments. The proper place for discussion is on the mailing list, in the dedicated discussion thread for each RFC. There, folks can give their comments, negative or positive, on the RFC and engage in a dialogue with the RFC author(s) and the rest of the community: hopefully with a view to arriving at the best outcome for the project. The barrier to entry for that collaboration is very low and open to all (well, almost all): this is A Good Thing™.
Requiring negative feedback to be copied into the wiki (or worse, only written in the wiki and not in the discussion thread) only adds more hurdles: the number of people who can edit the wiki is tiny compared to who can post to the mailing list, it necessarily cuts out the dialogue, it necessarily is not going to be exhaustive of all (negative) arguments (the exhaustive list should be in the mailing list discussion), it is splitting out content that really should be summarised in the RFC document proper - yes, I know authors have been hopeless at doing this historically - under "not pursued ideas", "known issues", "caveats", "considered but rejected" or similar types of headings.
Addressing some points in particular:
While you're right that it is work, so is taking positive feedback and ideas and including those in the RFCs, and that happens. So is fielding questions, feedback (particularly negative feedback), comments, discussions, etc. on the list, and that happens. I'm not sure it's really a case of "too much work", rather it's in the RFC author's interest to present the best case for their proposal: not necessarily present the best proposal for the project.
But it should. The RFC author should be spending time and energy discussion, addressing and documenting these things already. Digesting and presenting this feedback shows that the RFC author has understood what has been said, can summarise it, and ideally respond reasonably (even if that means marking the feedback as "won't pursue").
I don't see how copying contents of what should be in an email, on to the wiki, avoids any debate.
In summary, I think that RFC feedback should be kept to the dedicated mailing list threads, and that RFC authors (or someone delegated the task) should be urged much more strongly than now (i.e. more than not at all) to keep the RFC document up-to-date with references to discussions (many RFCs don't have have links to the mailing list archives for their discussion threads) and to have a section on key feedback (both positive and negative). That should become just an integral part to authoring an RFC, and not doing so could be a barrier to putting the RFC to vote.