search

w3c / webextensions

Charter and administrivia for the WebExtensions Community Group (WECG)
Other
595 stars 56 forks source link

Add guidance on the review expectations of proposals #576

Closed rdcronin closed 5 months ago

rdcronin commented 6 months ago

As we discussed at the in-person WECG meet-up, we should add expectations around review practices. This PR adds documentation for those practices.

rdcronin commented 6 months ago

I think all comments are addressed. @dotproto and @Rob--W , please take another look.

hanguokai commented 6 months ago

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.

rdcronin commented 6 months ago

@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.)

hanguokai commented 6 months ago

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. Developers' position and perspective are not always consistent with browser vendors' position and perspective. For example, "pushing more burdens to developers" or "significant breaking changes". So no matter how many browser vendors participate, they cannot replace developers.
  2. No matter how tech-savvy a person is, if they lack practical extension development experience, they may not be able to fully understand the issues that developers are concerned about and will not be able to come up with good proposals.
  3. "Find a developer as a reviewer" is much easier than "Find a "sponsoring browser" that is committed to implementing the proposal soon" (if you are a developer).
  4. Historically, some developer feedback was ignored by browser vendors. After thinking deeply, my conclusion is that developers "人微言轻"[1] and lack decision-making power. So, adding developers as reviewers could help improve this aspect.

[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.

rdcronin commented 5 months ago

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.

hanguokai commented 5 months ago

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?

rdcronin commented 5 months ago

In other words, it also implies that if a person joins or leaves a browser vendor, [their] 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.)