Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a proposal for the Interop 2024 process #390

Closed
wants to merge 22 commits into from
Closed
Changes from 7 commits
Commits
Show all changes
22 commits
Select commit Hold shift + click to select a range
93104fa
Add a proposal for the Interop 2024 process
gsnedders Aug 8, 2023
678df78
Move opening two sections of planning-process.md to new PR
gsnedders Aug 18, 2023
8071119
fixup! Add a proposal for the Interop 2024 process
gsnedders Sep 6, 2023
e22cdc3
fixup! Add a proposal for the Interop 2024 process
gsnedders Sep 6, 2023
afe00cb
fixup! Add a proposal for the Interop 2024 process
gsnedders Sep 6, 2023
b2ae8b3
fixup! Add a proposal for the Interop 2024 process
gsnedders Sep 6, 2023
8e9c82d
fixup! Add a proposal for the Interop 2024 process
gsnedders Sep 6, 2023
1fb6dbb
Apply suggestions from code review
foolip Sep 7, 2023
d825b88
Update planning-process.md
jensimmons Sep 28, 2023
6417e5c
Update 2024/planning-process.md
gsnedders Oct 4, 2023
7093980
Note parts are confidential
gsnedders Oct 5, 2023
6a599d3
Update 2024/planning-process.md
jensimmons Oct 11, 2023
fbc12e1
Update 2024/planning-process.md
jensimmons Oct 11, 2023
2bbe6f9
Update 2024/planning-process.md
jensimmons Oct 12, 2023
a5a4f1f
Update 2024/planning-process.md
jensimmons Oct 12, 2023
d95c7fe
Apply suggestions from code review
jensimmons Oct 12, 2023
e1bb8e4
Update 2024/planning-process.md
jensimmons Oct 12, 2023
9087fde
Update 2024/planning-process.md
jensimmons Oct 12, 2023
9ae26c3
Update 2024/planning-process.md
jensimmons Oct 12, 2023
52d9462
Update 2024/planning-process.md
jensimmons Oct 12, 2023
3d078cc
Update 2024/planning-process.md
jensimmons Oct 12, 2023
45744aa
Update 2024/planning-process.md
jensimmons Oct 12, 2023
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
134 changes: 134 additions & 0 deletions 2024/planning-process.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,134 @@
# Proposal for Interop 2024 Process

## Process

### Timeline — 10 weeks total
foolip marked this conversation as resolved.
Show resolved Hide resolved

1. Call for Proposal Period — three weeks (Sep 14 – Oct 5)
jensimmons marked this conversation as resolved.
Show resolved Hide resolved
2. Continued discussion and refinement of proposals — one week (Oct 5 – Oct 12)
jensimmons marked this conversation as resolved.
Show resolved Hide resolved
3. Elimination Round 1: Disqualification — one week (Oct 12 – Oct 19)
jensimmons marked this conversation as resolved.
Show resolved Hide resolved
4. Elimination Round 2: Reduction — two weeks (Oct 19 – Nov 2)
jensimmons marked this conversation as resolved.
Show resolved Hide resolved
5. Elimination Round 3: Prioritization — three weeks (Nov 2 – Nov 30, exc. North America Thanksgiving)
jensimmons marked this conversation as resolved.
Show resolved Hide resolved


foolip marked this conversation as resolved.
Show resolved Hide resolved

### Call for Proposal Period

An open call for proposals will begin on a specific date, and run for three weeks.

1. Anyone can submit a proposal.
2. Proposals should be for either:
1. Focus Area, or
2. Investigation Project
3. Related proposals should be filed separately. For example, all the ideas for “Web Compat” should be filed as a set of separate issues, not one issue. This makes it easier to discuss and prioritize each separately. Bundles of proposals risk being rejected or deprioritized.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So, broadly that's what we did the first year for webcompat, and then we switched in 2023. One reason was that sometimes the web compat proposals have been very small; possibly literally just one bug. At that level it seems like a lot of overhead to file multiple issues. On the other hand the process in 2023 wasn't perfect either and there was some confusion about what was included. so I don't object to changing back, but my concern is that people end up filtering out individual proposals because they're "too small" when in fact the intent was to group them all along. This particularly applies if there's a fixed size for the priority list below.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changing to be a different example, since, right, Web Compat is likely an exception to this guideline.

jensimmons marked this conversation as resolved.
Show resolved Hide resolved
4. Focus Area proposals must:
1. Name a specific web technology.
1. This can be a web technology that has not yet been implemented in any or all browser engines.
2. Or this can be a web technology that has already been implemented in all three engines, but those implementations have test failures that reveal a lack of compliance to the web standard, causing a lack of interoperability.
2. The feature must be defined in a sufficiently mature standards-track web specification from one the following organizations. Please provide link to the web standard.
1. [IETF](https://www.ietf.org/) (Standard Track)
2. [Khronos Group](https://www.khronos.org/)
3. [TC39](https://tc39.es/) (Stage 2+)
4. [W3C](https://www.w3.org/) ([Recommendation Track](https://www.w3.org/2023/Process-20230612/#rec-track))
5. [WHATWG](https://whatwg.org/)
3. Describe the benefit to web developers and the web itself
4. Link to existing tests (if any) and/or describe plan to create needed tests
5. Investigation Project proposals must:
1. Outline their scope and their goals,
2. Not substantially be work better suited to a group within a standards development organization,
3. Clearly provide present or future impact on cross-browser interoperability.

As soon as each proposal is submitted as a GitHub issue, discussion of that proposal can begin. Questions can be asked. The proposal can be edited and refined.

At the end of the three weeks, the deadline will end the period when brand new proposals can be submitted.

A fourth week will allow for continued discussion and refinement of already-submitted proposals. The deadline at the end of the fourth week ends the opportunity to significantly change the scope of proposals. The proposals will be evaluated on their state at that time.


## Focus Area Selection

### Elimination Round 1: Disqualification

After the Call of Proposals Period has ended, the Interop Team will finalize an official list of all Focus Area proposals.

Any Focus Area proposal that does not meet the minimum publicly-stated selection criteria will be considered for preliminary elimination. For example:

1. The proposal is overly vague or broad.
2. The proposed technology is already interoperable according to WPT results.
3. The proposed technology is not on a standards track, or its standard is not sufficiently mature.
jensimmons marked this conversation as resolved.
Show resolved Hide resolved

Decisions will be made at a specific meeting for discussion of preliminary eliminations. Any member organization can bring up a proposal they believe should be eliminated. Brief debate can be had. If **there is quick consensus**, that proposal will be eliminated. If there is not consensus and a longer debate is needed, the proposal will be not be eliminated and will instead move on to the next round.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's unclear to me what the value of not eliminating if anyone proposes elimination is. Or at least: if someone makes it clear that they will veto a proposal in later rounds it may as well be eliminated early.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As I see it, the value is twofold:

  • Preventing this phase from taking too long
  • Opportunity to convince those who propose elimination otherwise in the next round, with additional evidence

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My supposition is that if you're proposing elimination early you're pretty sure that the proposal won't reach consensus (e.g. because there's a negative standards position). Given that a lot of the process is about reducing the overhead I'd personally err on the side of believing people if they say that something isn't worth carrying forward.

I agree that there could also be a situation in which people think that maybe something should be eliminated, but are more open to extended discussion in the next phases. In that case we should of course keep the proposal in.

Maybe the wording is fine, as long as people understand that there is basically no advantage to retaining a proposal that a specific org clearly indicates it's against at this stage.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Preventing this phase from taking too long

@chrishtr I'm confused by this part of your comment. Doesn't this inherently involve this and all other phases taking longer than if we just said "ok, let's take that one off the table and work on the convincing somewhere else/for next year"? Presumably if someone is saying that at this phase, as @jgraham says it's for real reasons (like a negative and public standards position that we can point to in the disqualification notification) or something pretty significant (chrome, for example, said no to several things while in the process of redoing the layout engine because that makes it that much harder)... I think it seems pretty easy to present, have the group accept that and move on. This doesn't seem like the venue for convincing on all things, right?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it seems pretty easy to present, have the group accept that and move on

Nevertheless this will take time, and it's hard enough to make decisions already. The purpose of rounds 1 and 2 is about efficiency of easy decisions, so we should stick to easy decisions and not ones where there is any debate at all.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, as @chrishtr says—it's about making non-controversial decisions quickly.

It's also intended that the first round doesn't have too many subjective decisions—a spec either does or does not meet the criteria we've set (and I hope we don't get into disagreements here!), tests already show interoperability or they don't (we can of course get into a debate about whether the final 5% matters!), though "overly vague or broad" is much more so subjective.

@jgraham: was your original question intended to be "why not let people veto up front, for any reason"? if so—the current kinda short list of reasons for disqualification are there because they're largely what we practically did in prior years, and because things that are largely objective are likely easier to get consensus on.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it possible that vagueness is causing us to be talking about completely different things? I think yes let's ask people to 'veto' here, and not at the end. That is what I am saying - I might be completely alone in this... But honestly, I also kind of dislike that we're even using words like "vote" and "veto" at all because they conjure up something that I don't honestly think is really happening here. I understand why, it's a kind of vote - but really what we're doing is more like using some joint worksheets to do complicated sorting and planning and negotiate (with what little power any of us actually has to do so) some plausible subset of things we all agree we could work on improving interoperability of.

Let's say two concrete examples:

  • Somebody submits that we should work on interoperability of the is="" attribute. It's in the WHATWG HTML spec, which I think has always had the same definition "two in favor, none opposed". Except Apple is opposed, and has a public position many times stating as much, including a recent WebKit standards position. So... Is it disqualified in that case? Or does this require a "veto"? If the latter, we can say it now, why drag it out. It's just a particularly easy example, but it's not unique: People are going to submit things that have negative standards positions - is this the venue to debate it? I kind of think not.

  • Somebody submits we should work on 'all the color stuff' a few years ago and it's pointed out that this requires much low level rework in order to actually bring the value, so it's not likely something that would actually improve this year and there are lots of other things where we think we could all agree and get stuff measurably done and shipped --- but hey we are actually working on all that low level stuff and totally support it! That isn't currently disqualified, and it's certainly not a "veto" - but it's a known known and it seems to me the group could choose to say "that seems totally reasonable, let's just exclude it" and doing that as early as possible just seems good... To me.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's say someone proposes "Geolocation Sensor" for Interop 2024. It has a spec on a standards track at W3C, and tests. So per the criteria given we can't eliminate the proposal at this stage. But it also has multiple negative standards positions, and no evidence of implementations going ahead despite those standards positions.

It seems like a pretty safe bet to me that proposal is not going to reach consensus.

But per the process here, we have to take it forward in case we want to have a longer debate at some later stage. But it's not clear to me what form that debate could possibly take, and indeed debating proposals as a group isn't part of any of the later stages of the proposed process. So assuming at least one org is in favour in round 2, the proposal has to go all the way through to round 3, even though we had the information in round 1 to know it wasn't going to reach consensus (because a participant could have said so).

Obviously this isn't the most serious concern; eventually we'll incorporate the information that the proposal isn't going to reach consensus, and it won't get selected. But it is an inefficiency in a process that claims to be optimising for making the best use of everyone's time.

Copy link
Member

@foolip foolip Sep 7, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be great to keep round 1 relatively objective and efficient. As @gsnedders says, "things that are largely objective are likely easier to get consensus on." By only eliminating things that we all agree about, it also makes bookkeeping very easy, and we can do this in a single meeting as proposed.

I do agree there's value to eliminating early if one organization knows they'll veto it in round 3. How about we allow for vetoes also in round 2 to avoid the more time-consuming round 3 for those proposals?

Concretely: proposals move on from round 2 if they have some support and no objections.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, strike that, I don't want to complicate things at this point with suggested changes to the process.


1. Setup *Disqualification meeting*
2. Each organization can propose items for disqualification.
3. Brief debate on each proposal:
1. if there is quick consensus, disqualify the proposal
2. otherwise, send the proposal to Round 2
4. Publish the list of proposals pushed to Round 2.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wait what? In public? We should debate this. Please see GDoc for more. https://docs.google.com/document/d/138F0bzFwywci9p5q7HMP4Rbi9E0iBjz4s0ZC6IE9324/edit#heading=h.jeelvxhy0wl3


### Elimination Round 2: Reduction

At this point, there is a clear list of Focus Area proposals under consideration. Each organization has two weeks to review the list of proposals and make Round 2 decisions.
jensimmons marked this conversation as resolved.
Show resolved Hide resolved

Each member organization chooses `N` number of proposals they would like to see move on to Round 3. There is no ranking or scoring at this point, a simple “yes, we want this proposal to stay in consideration”. Once all the “yeses” are gathered, any proposal that does not have the support of at least one organization is eliminated.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't understand how this will work in detail.

Incoming proposals may be different sizes. Per the above text some proposals may be far too small to form a focus area on their own. So in order to do fixed-N selection I think we'd need to have already grouped the proposals into similar sized chunks at this point. Otherwise it's impossible to compare proposals like "fix one small but important bug" and e.g. "implement an entire new CSS layout mode".

Also it's unclear how to pick N. We probably need N large enough that we're guaranteed to get enough proposals that Interop 2024 is a reasonable sized project. But given overlaps and possible later vetos, that doesn't seem possible without allowing the process to be iterative. One point of view is "well even if we only end up with five focus areas, we'll know those are the most important ones". But I think that would be a mistake if we end up rejecting things that everyone does in fact end up working on just because Process.

Copy link
Contributor

@jensimmons jensimmons Aug 14, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

N should be "slightly too large".

If you imagine we expect 35 proposals and 20 "open slots", then figuring out N does seem impossible. And honestly, this whole step could be skipped. Just take all 35 proposals to the next round.

But if you instead imagine we could get 150 proposals and have only 5 open slots... then this step makes more sense. It's a way to make a huge cut very quickly to get the number of proposals into a reasonable number. Why sweat the details over which is ranked 82nd and which is ranked 97th if we are only accepting 9 new areas?

We won't know how many open slots there are, but we could guess, for instance, it's 15 at most (probably less) (after grouping), as so... we could make N be... 35? Or 55? And cut the rest of the proposals in case many more than that come in.

We probably need N large enough that we're guaranteed to get enough proposals that Interop 2024 is a reasonable sized project.

Exactly. And it's fine if N is "too high". It's really just a protection against having way too many proposals in the later stage of the process, just in case the success of and attention on Interop 2021-23 brings us exponentially more proposals yet again this year.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the fundamental problem with this as stated is that there's no way to pick N that works with proposals of very different sizes. For example it doesn't make any sense to have to pick between a proposal that represents a full focus area like "implement an entire new CSS layout mode" and one that's a small DOM bug that causes webcompat issues, and would be merged with many other proposals to form a full focus area.

Assuming we do get different sized proposals, it seems like we'd either need to collectively try to size/group proposals earlier in the process, or allow people to propose their own groups at this phase, or not fix N, but ask people to pick a number of proposals that they feel reflects a reasonable size for Interop 2024, and allow that to vary between participants.

(The other possibility is that we just don't get so many proposals that this stage is really needed).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 to jgraham's comment above about selecting 'N' being particularly tricky. Suggest each organization pick a reasonable number of proposals that are well-justified and that they can support.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One of the big questions that came up in the meetings in recent weeks was the question of when to do the grouping; it might be worth revisiting this after deciding when to do the grouping?

Copy link
Contributor

@jgraham jgraham Sep 7, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How to do any grouping, and how to estimate/balance the overall size of the focus areas, seem like the most fundamental remaining issues. Previously we did that at the last minute by "feel", but that doesn't work well with the process set out here due to the ordering step.

Grouping before ordering doesn't work if that happens before the proposals have got detailed input from engineering teams, because we might group things that have very different levels of complexity or priority, and then be forced to assess the group as a whole on the basis of its worst elements.

But trying to order things of very different size and complexity also doesn't seem to work well (how does one tradeoff "fix a single test that represents a serious webcompat issue but is probably a few days of work and isn't going to be a focus area on its own" against "implement an entire new platform feature that could take multiple months of work"?).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The suggestion I like the best so far is this one from @jgraham:

ask people to pick a number of proposals that they feel reflects a reasonable size for Interop 2024

I think there's general agreement that we should not increase the number of focus areas, so at the very very most this could be 26.

This does require each organization to make some qualified guesses about what will make sense to group after round 3. In the case of web compat bugs this is easy. For some other proposals there might be disagreement, but the only effect of this is that a few more proposals move on to round 3.

Corner case consideration: Elsewhere I suggested we should also allow for vetos in round 2. If we do this, then there's no guarantee that we have N proposals after round 2. I think this is very unlikely, but if it does happen we could do another round of round 2 for the remaining slots. Presumably there would be no vetos that time.


For example, let’s imagine there are 112 focus area proposals submitted. Let’s set `N` to 10 — so each of the six organizations gets to choose 10 proposals. There will likely be significant overlap, but not complete. So imagine 32 proposals get chosen by at least one organization. (It will be no less than 10, and no more than 60.) This means the remaining 80 proposals are eliminated.

If `N` is increased, then more proposals will make it into the next round. The goal is to find a balance so all of the proposals that are most likely to be considered high priority will make it into the next round. While eliminating as many as possible, to reduce the workload of the Interop 2024 organizations. There’s no need to extensively evaluate proposals of lower priority.

### Elimination Round 3: Prioritization
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One concern with this overall approach is that it doesn't provide an easy way to balance the overall composition of the project. For example it might be that we get two strong proposals for including, say, two different DOM Storage APIs in Interop 2024. In that situation there are a variety of theoretical and practical reasons why we might not want to put both in (e.g. concerns about too much churn, practical resource constraints, wanting the metric to be more balanced across the entire platform).

In the previous setup each org might choose the one proposal they thought was highest value and object to the other one. In the worst case this could lead to neither being included, which isn't ideal, but isn't worse than the status quo. In this process you might have some orgs rating one proposal high and the other low, and some doing the opposite, with the end result that both are included, even though that outcome isn't what anyone wanted.

I don't know to what extent a formal process change is needed here, vs just discussing any such concerns, but one can imagine at least trying to group the proposals by area of the platform and prioritising each separately.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you still have this concern, James? If so, any suggestions about how to address it? (I recommend reading the current language in the GDoc, and commenting there.)


The official list of Focus Area proposals is updated to reflect the elimination of proposals not chosen by any organization. Each organization now has 20 days to review the list of remaining proposals and make their Round 3 decisions.

In this round, each organization ranks the proposals in order of importance from most to least. And submits any vetos they may wish to exercise.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
In this round, each organization ranks the proposals in order of importance from most to least. And submits any vetos they may wish to exercise.
In this round, each organization ranks the proposals in order of importance from most to least. And submits any vetos they may wish to exercise, with a brief rationale for the benefit of the Interop team.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think the process can require a reason for exercising a veto. Of course I also hope in most cases people will be able to articulate reasoning, but nevertheless.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indeed we can't require a reason, how about we make it clearly optional but encouraged:

Suggested change
In this round, each organization ranks the proposals in order of importance from most to least. And submits any vetos they may wish to exercise.
In this round, each organization ranks the proposals in order of importance from most to least. And submits any vetos they may wish to exercise, if possible with a brief rationale for the benefit of the Interop team.


Any proposal that gets a veto is immediately eliminated.
jensimmons marked this conversation as resolved.
Show resolved Hide resolved

Each proposal gets assigned points from each organization, according to their rank, and an ordered list of all remaining proposals is created. Where `X` is number of proposals that are ranked, and `Y` is the ranking a particular proposal gets from a certain organization, then that proposal gets `X-Y` points from that organization. Once all 6 rankings are in for that proposal, the total points from all six organizations is known. If that proposal is not eliminated by a veto, then it has a certain number of points, and can be listed in order among the other proposals.
jensimmons marked this conversation as resolved.
Show resolved Hide resolved

For example, if there are 20 remaining proposals, each organization will choose a number 1, number 2, down to number 20. Let’s say a proposal for flying cars gets the following ranks: 1, 5, 7, 10, 14, 20. That will give it the following points: 20, 15, 13, 10, 6, 1 = 65 points total.

(If there appear to be quite a few proposals remaining in this round, the group can decide to only ask for each organization to submit their Top `X` number, while rating the rest zero. For example, if 50 proposals remain at this point, it likely makes sense to only submit a Top 25, and to not worry about ranking 26-50 in a specific order.)

After Round 3, every remaining proposal can be listed in order, with the group’s highest priority at the top, and the lowest at the bottom.
jensimmons marked this conversation as resolved.
Show resolved Hide resolved

NOTE: in the past, “Exclude” was a way to express many different kinds of sentiments — including: does not meet the minimum qualifications, or this is low priority to us. We expect “veto” to be used much less than “exclude”, because there are other ways to express those sentiments. Vetoing is specifically for objecting to a particular proposal being included *at all,* no matter how highly ranked other organizations might find it. It’s for expressing objection to a particular web technology, perhaps to something an organization has already expressed an objection to in the web standards process or otherwise has an objection to implementing.
jensimmons marked this conversation as resolved.
Show resolved Hide resolved
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
NOTE: in the past, “Exclude” was a way to express many different kinds of sentiments — including: does not meet the minimum qualifications, or this is low priority to us. We expect “veto” to be used much less than “exclude”, because there are other ways to express those sentiments. Vetoing is specifically for objecting to a particular proposal being included *at all,* no matter how highly ranked other organizations might find it. It’s for expressing objection to a particular web technology, perhaps to something an organization has already expressed an objection to in the web standards process or otherwise has an objection to implementing.
NOTE: in the past, “Exclude” was a way to express many different kinds of sentiments — including: does not meet the minimum qualifications, or this is low priority to us. We expect “veto” to be used much less than “exclude”, because there are other ways to express those sentiments. Vetoing is specifically for objecting to a particular proposal being included *at all,* no matter how highly ranked other organizations might find it. It’s for expressing objection to a particular web technology, perhaps to something an organization has already expressed an objection to in the web standards process or otherwise has an objection to implementing. A veto should when possible come with a brief explanation to the other Interop Team members to help them understand the reasoning, and further encourage scoring rather than vetoes.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
NOTE: in the past, “Exclude” was a way to express many different kinds of sentiments — including: does not meet the minimum qualifications, or this is low priority to us. We expect “veto” to be used much less than “exclude”, because there are other ways to express those sentiments. Vetoing is specifically for objecting to a particular proposal being included *at all,* no matter how highly ranked other organizations might find it. It’s for expressing objection to a particular web technology, perhaps to something an organization has already expressed an objection to in the web standards process or otherwise has an objection to implementing.

I still think this note, whilst non-normative, is nevertheless misleading and that it remains acceptable for participants to veto any proposal for any (public or private) reason. Although I agree with the sentiment that direct vetos are less likely in the proposed process, I don't think the Process should try to hint at the existence of legitimate and illegitimate categories of reasons to veto, particularly given that we don't have experience of how things will play out in practice, and so don't know what will actually be required to end up with a final result that everyone can approve.

(If this PR is merged, as per the previous meeting notes, I will reopen this as a new PR).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This has already been removed. Have you checked the Google Doc draft? That's where the current draft is. This PR is now irrelevant.


## Interop 2023 Evaluation

During the same period organizations are making Round 3 decisions, the Interop Team should evaluate the status of Interop 2023, and decide which Focus Areas will be retired, and which will be carried over.

\[XXX]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This appears to still be placeholder text?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This has been addressed in the current draft, in GDocs.


* * *

# Decision point — what to do about Interop 2023?

## There seem to be 3 options:
jensimmons marked this conversation as resolved.
Show resolved Hide resolved

### 1. Assume carryover. Retire some. Add how many ever that leaves space for.

1. Start with the assumption that all Interop 2023 projects will be carried over — except for the ones that are “complete”
jensimmons marked this conversation as resolved.
Show resolved Hide resolved
1. Figure out a process for determining what should be retired.
1. Perhaps by voting for each proposal one-by-one, to keep it or not (that’s what we did last year).
2. Perhaps by score — everything above 95% Interop gets retired, or something similar.
2. Decide how many total Focus Areas we want for Interop 2024. Perhaps 20? 15?
3. That determines how many “open slots” we have.
1. 26 - the number retired = the number carried over.
2. If we are aiming for 20 areas in 2024, and 18 are carried over (retiring 6)... then we have space to add 2 new areas.

### 2. Automatically ‘reapply’ all Focus Areas

1. Carryover nothing.
2. Take all 26 Focus Areas from Interop 2023, and put them into the selection process.

### 3. Make every Focus Area ‘reapply’
jensimmons marked this conversation as resolved.
Show resolved Hide resolved

1. Carryover nothing.
2. Let people propose any focus area they believe is worthwhile still having included.

* * *

# Decision point — Investigation Project Selection

Largely the same as Interop 2023?