Retrospective on process and launch #68
Comments
|
Discussed in #69 Brian: It's a bit early to say if it worked well or not. James: For gather positions, hopefully next time we'll have a clearer shared understanding to avoid last minute changes. But big picture nominations and consensus worked well. Philip: Typography and Encodings. [to flesh out later] Simon: I'd like a clearer plan and timeline, it was a bit last minute for us. Brian: It took time to sort out things we'd never done before and we had time pressure, and then world events. |
|
FWIW: I started writing something longer a while back, but I never finished it. I probably should finish it. |
|
@gsnedders I also have a half finished thing. Maybe we can just post our unfinished thoughts? 😀 |
|
Here are my initial thoughts on how Interop 2022 positions worked. Overall, I'm very happy with the outcome, for example Subgrid, Cascade Layers, and Forms are focus areas that I think will be noticed by web developers, and the Support/Oppose/Neutral method of establishing consensus worked well here. However, I think the way we did proposals and sub-proposals turned out suboptimal since we ultimately had to consider each sub-proposal individually and then group things back into focus areas afterwards. With the Typography and Encodings proposal (originally just Typography) I think good features were included, but @drott and I considered color fonts to be the strongest part of the overall proposal. Here are the positions for the sub-proposals that led to that being excluded:
That is fair of course, that's the process we all agreed to. But from Google's point of view, the most compelling part of the focus area was missing. A few thoughts on changes we could make for Interop 2023:
In addition to the procedural, we should also consider ways of just continuing the conversation, to resolve things by mutual consensus and not by following predefined rules. We were quite light on the formal rules for Interop 2022, and I think that was a strength. |
|
So replaying the decision tree, but with Google objecting to the fonts proposal unless color fonts were included, it seems to me that that most likely outcome would have been that we dropped all of the fonts-related work from Interop 2022. It's not fully clear to me that represents a better outcome, but it's of course possible that would have been people's preferred option. I agree that in practice sub-proposals are the level of granularity required to assess whether something should be included (because they correspond more directly to resourcing questions for implementors and user impact), and proposals are basically a way of trying to produce a "fair" weighting of the overall metric. I don't know I have a concrete proposal to improve that (weighting seems inherently somewhat arbitary), but I agree that we should be more explicit about how that works going forward. |
I'm not entirely sure I would have preferred that, or that we would have objected to the whole focus area if we did have a second round of positions after grouping. But if we had thought about this problem ahead of time, we would have spent more time thinking it through and discussing with the group. |
I think it's worthwhile stepping even further back than that; one thing that was clear to me was we didn't actually have a good grasp on what exactly the goals were, and what the inclusion criteria was. AIUI, the goal with Interop 2021 had been to target known developer pain-points, both in terms of browser incompatibilities and fulfilling feature requests. Some of the challenge with some of the proposal discussions, far as I can tell, is a lack of agreement about the underlying goals of the project even were. It's very hard to evaluate a proposal when you haven't agreed what the goal of the proposals even is. If we took that statement as the statement of the goal, then we can evaluate proposals against that, potentially with a set of guided questions like:
These are questions where we can have pretty concrete discussions about. And that's before we get into more nebulous questions about whether or not we allow browsers to oppose inclusion of certain features for unspecified reasons. We can even include such things as part of the proposal template. Otherwise, the big part of chaos was down to the proposal v. sub-proposal "issue" as discussed by @foolip above; I think practically trying to do anything with explicit grouping until we know what's actually in is probably not overly worthwhile, and that the right thing to do is to first go through individual proposals (which can actually be evaluated v. the above questions, versus many of the discussions we had internally which were "this is incredibly undefined what this [huge area] is, and our views depend on what is actually intended to be included"). So yeah, my concrete suggestion there is to evaluate things at a meaningful level, and then come up with some proposed grouping—acknowledging we may either need to fudge it somehow or drop certain proposals.
I don't think that's answerable without actually defining the goals of the project more clearly.
I think it was mostly okay; some of the challenges were in the definition of "investigate", and what this meant in terms of any real commitment to move forward with anything.
Aside from the unfortunate delay, I think this went relatively well, though perhaps more time to allow for cross/internal reviews of posts would've been good? |
@gsnedders I like the questions! There's probably some room in there as well for how useful and used that area is, e.g. there are pain points but for features not much used by the broader developer audience (and likely never will be either, even if the pain points have been addressed). |
|
I think that there can be pain points that don't affect a lot of developers but do affect a lot of users. For example in features that are typically used via a library rather than directly it might be that only a few developers (those working on the library) ever encounter the interop issue in their own code. But if the problem means that sites break in certain browsers it can nevertheless affect a lot of end users. Another framing here is that the Priority of Constituencies still applies and should be part of the decision making process. |
|
I agree that we shouldn't use the proposal/sub-proposal structure again, that created some unnecessary problems. Doing away with it does seem to necessitate a second decision step after the positions, however, as @gsnedders is getting at here:
I think we could do this in a group discussion without too much trouble, and maybe that would be enough. I would like to avoid adding a second step in the style of "now everyone feel free to veto anything, no questions asked", because that might nudge us all in the direction of being less careful in the first review/positions step, and creating frustrating vetos in the second step, souring the effort. |
|
@gsnedders when it comes to alignment on goals, one practical thing we could do is to write down some principles for the effort, things that we are already largely aligned on. And I think questions around those principles would make sense for the proposals template and when evaluating them. However, I think we will have to accept that we don't all have the same prioritization approach, and that any vendor might have reasons for opposing a proposal that they can't be entirely transparent about. But we might still be able to move in the direction of a shared prioritization lens, without getting all the way there. |
|
Attempted summary of our takeaways:
|
|
I guess one process question is whether this is all being handled by the Interop team or if any of this is going back to the Core team, which I guess would be the latter if we want to amend the RFC to clarify any of the above? |
|
Also discussed today: Do we want a clear call for public proposals? Do we want to seek input (probably not voting) from the public? |
Interop 2022 launched on March 3, 2022, with a lot of buzz and excitement.
While it's still fresh in memory, I think it would be good to look back at the whole process and launch, and record learnings for Interop 2023. Some probing questions:
The text was updated successfully, but these errors were encountered: