Agenda for July 11th, 2024

[foolip]

Here is the proposed agenda for the meeting on July 11th, 2024:

• Identify action items from signals discussion. Any updates to proposal templates?
• 2025 proposal selection process #657

[jensimmons]

Test change proposals?

We'd like to get approval for this: #672

[foolip]

Brief notes from yesterday's meeting:

Attendees: @bkardell, @jgraham, @dandclark, @foolip, @stubbornella, @nt1m, @meyerweb

• Consensus to exclude XR tests in Tests of requestVideoFrameCallback Focus Area should not require support for WebXR on desktop #672
• Follow up from signals discussion. Any changes needed on proposal templates?
  • @stubbornella: Main thing for us was a shared understanding. Maybe giving some examples would be helpful.
  • @bkardell: There would be value in writing something (anywhere) that we can point to.
  • @jgraham: The current process proposal says that we’ll write something to inform proposal authors. The templates didn’t work very well last year, so should we cut back a bit on those? Instead, we have “please read these guidelines” which mentions signals that we’ll consider.
  • @stubbornella: That makes sense to me. We’re going to validate signals anyway, so having proposers fill in the template doesn’t reduce our work. The champion for each proposal can do it, and would anyway.
  • @dandclark: I worry that people won’t follow links and read the docs. But I don’t object to trying this.
  • @jgraham: You’re probably right, most people didn’t read it when it was in the template even. It’s a bit about having something to point to to explain what we’re taking into consideration. Not just for proposers but anyone who’s hoping for a certain outcome.
  • @foolip: Agree this all makes sense. Too much template in past years.
  • @jgraham: I think we need (1) in public, things that we’re looking for in a proposal and (2) internally, a shared spreadsheet for the objective signals.
  • @stubbornella: Can we volunteer you for the first bit?
  • @jgraham: I can start a PR which we can get feedback on.
  • @stubbornella: I’m happy to look at the shared spreadsheet. There’s a question of whether we make it public. It’s hard to judge and I don’t want web developers to be discouraged.
  • @jgraham: I think it should be confidential.
  • @dandclark: Sharing it would be useful to learn if we’ve made a mistake, and it wouldn’t be attributed to any of us.
  • @stubbornella: The part that wouldn’t work in public is if I survey our engineers. I’ll need to think that over.
  • @dandclark: It would have to be clearly messaged. Once we have a spreadsheet we can discuss.
  • @stubbornella: Good point. Let’s try to make it useful for us first.
  • @jgraham: Conclusion is let’s make a spreadsheet. If it’s just a collation of public data then that might be easy to share. Maybe even some value judgments. Starting point is make something that’s useful to us. If the end product would be useful to share, we can have a call for consensus.
  • @foolip: I volunteer to send a PR with updated proposal templates.
• 2025 proposal selection process #657
  • @foolip: What are the decisions we need to make before we can have a call for consensus for the whole process?
  • @stubbornella: In a previous meeting we talked about publishing roadmaps, and that’s something we should all be free to do. That’s different from sharing how we voted.
  • @dandclark: [reads wording] The second part is about roadmaps. Then there’s the question of sharing what we decide to champion. If we chose to, we could make our championing public, perhaps as a blog post. There can only be one champion. It’s incomplete information, so it doesn’t reveal too much.
  • @bkardell: I think this is almost OK. I think it needs to come with a standard disclaimer. The purpose of this group is to discuss and agree. Positions could change. The disclaimer should be that this is the beginning of the process and of course our positions might be informed
  • @foolip: Glad to hear that there’s agreement about reasonableness of sharing roadmaps independent of Interop. Regarding the limit on one champion, Dan, was your suggestion to share “would like to champion” or what was actually championed, making it lossy? The former would make sense for us I think.
  • @dandclark: I’d be open to either way.
  • @stubbornella: On sharing roadmaps, if Microsoft says “we’re going to ship X” outside of Interop is valuable for developers to know, and avoids the complexity of inferring things from multiple pieces of information.
  • [@foolip couldn't keep up scribing here]
  • @bkardell in chat: Is there something preventing someone from just saying "we approve of everything" and then making everyone else look like a jerk? :) But here's a kind of counter question... Say before we meet, I write a blog about the proposals we recieved and the ones I personally find really interesting... Is that valid?
  • @stubbornella: My personal goal for this year is to build trust in this group. Not playing games about who said what helps with that.
  • @jgraham: I think the only version that can work is if we publish all of what anyone champions. You could then tell from that list which proposals didn’t make it to that stage. I think there is a line here where it’s positive messaging, that each organization is taking some proposals and we’re making the web better together.
  • @stubbornella: If an accessibility doesn’t get a champion, we could get flamed for that, even if there are good reasons it didn’t get taken on. And I will not be able to share plans in the way you’re discussing.
  • @dandclark: People will be upset, but I don’t think we can prevent that by dropping all the outcomes at once. I see it as an opportunity to drive excitement in the process.
  • @foolip: If we want to share what Interop proposals we’re excited about in the way that Brian suggested, that should be fine. If we can’t agree to publish the list of all champions, then we should still be able to do it individually.
  • @bkardell: Dan has proposed two sentences. The roadmap one is entirely uncontroversial. Can we tweak the other sentence in some way? We shouldn’t try to prevent people from talking about what they’re excited about. We’ll know early in the process some proposals that aren’t going to make it. I think it would be better to communicate early when we’ve eliminated proposals after we’ve picked champions.
  • @jgraham: What I think could wor is if after selecting champions, we publish a list of proposals moving forward and who is championing them.
  • @dandclark: I’d be happy with that.
  • @jgraham: If some people publish and some don’t, that’s a bit confused, what does it mean? We have to be prepared to tell people earlier on that their proposal has been rejected. It will feel like a stronger rejection even if it isn’t.
  • @nt1m: If we do publish something it’s important for the group to speak with one voice and that we don’t turn it into a battle between who championed what. I don’t know if Apple is able to publish what we’re championing.
  • @dandclark: For proposals that are dropped early for lack of test, the proposers can improve that for next year sooner rather than later.
  • @jgraham: What I’m hearing is that we don’t have consensus on this. Some people are saying “we’re championing these things” and Apple can’t do that. To publish just which proposals are moving forward is probably not going to make anyone happy.
  • @bkardell: Do a PR for the first sentence? ("Participating organizations are free to publish the list of proposals that they choose to champion and their reasoning for choosing them.")
  • @stubbornella: I agree with that. There are different dynamics for what’s internal and external in different organizations. Doing the first sentence as a separate PR makes sense. We could have a discussion about that.
  • @nt1m: If we give feedback on early rejections, that might help people create better proposals.
  • @stubbornella: Doing it well and kindly is also a lot of work.
  • @jgraham: Not all early rejections would be for technical reasons, there’s still the cases that weren’t a priority for anyone.
  • @dandclark: Agree that rejections need to be handled with sensitivity, whether early or late. It seems like we don’t have consensus, I’ll take the action to split the first sentence into a separate PR. The situation on confidentiality is untenable for us.
  • @foolip: It was a problem for us last year and we’ve discussed this many times. Wish we could make more progress than we’re making, so thanks Dan for driving.