Add guidance on the review expectations of proposals #576
Conversation
As we discussed at the in-person WECG meet-up, we should add expectations around review practices. This PR adds documentation for those practices.
There was a problem hiding this comment.
Description is quite wordy, but matches my understanding of what we have discussed.
The distinction between "proposal is in an acceptable state (well formed, etc.)" and "browser engine supports the implementation" isn't clearly expressed, but I see that Simeon had already raised that and will let him handle that. We try to align in this group, but there will eventually be APIs that are adopted by part of the group and opposed by others. That shouldn't prevent a proposal from being merged.
|
I think this process lacks reflection of developers' opinions and is more about collaboration between browser vendors. So, I recommend that at least one of the reviewers is not affiliated with any browser vendor and has developed at least one extension with at least(>=) 500 users. |
|
@hanguokai I definitely agree that developer feedback is a critical aspect in API proposals! Since the current editors and chairs of the WECG are affiliated with browser vendors, I'm hesitant to add "find an extension developer" as a necessary step in this process. Additionally, we're already at the point of having 3+ different reviewers, and review by consensus doesn't scale. I think we absolutely should (and do!) welcome developer feedback on proposals and in the issues that likely led up to them, but I don't think we'll have it as a gating switch on proposal submission. However, I do think that if there's clear developer feedback that isn't addressed, browser vendors will take that into account and request it be addressed before they sign off. (For instance, if I were a reviewer on a proposal and a developer raised significant questions that weren't addressed, I'd ask the author to please address those before I approved the proposal.) |
|
I don't want to block the approval of this PR here because these issues can be gradually improved in the future. Here are my personal opinions:
[1] In one's humble position, one's word does not carry much weight.; The words of the lowly carry little weight.; When a man is in a low position, his words are of little effect. |
|
I think we're all aligned that incorporating developer feedback is critical for success, and the intent here is definitely not to circumvent or minimize that. We will definitely solicit (and listen to) developer feedback on proposals, though, of course, we may not always be able to satisfy all parties. I don't think we'll change this to have a developer have sign-off power on proposals, but I will create a separate PR that indicates more clearly that developers should be empowered to, and encouraged to, provide feedback on API proposals and that browser vendors should consider this feedback during the review. |
I don't pursue unrealistic results, on the contrary, I pursue the best possible results. So, this result is acceptable to me (I represent myself here, not other developers). In other words, it also implies that if a person joins or leaves a browser vendor, his or her reviewer role will change automatically, right? |
Yep, I'd say so. They can, of course, continue to provide feedback as a developer and someone familiar with the ecosystem, but they would no longer have a "blocking" review. (And note also that even vendors don't have fully blocking reviews. These guidelines are more about timeliness to ensure we don't get bogged down.) |
As we discussed at the in-person WECG meet-up, we should add expectations around review practices. This PR adds documentation for those practices.