Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Add a proposal for the Interop 2024 process #390
Changes from 16 commits
93104fa
678df78
8071119
e22cdc3
afe00cb
b2ae8b3
8e9c82d
1fb6dbb
d825b88
6417e5c
7093980
6a599d3
fbc12e1
2bbe6f9
a5a4f1f
d95c7fe
e1bb8e4
9087fde
9ae26c3
52d9462
3d078cc
45744aa
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Regarding the confidentiality wording added in 7093980, there's a proposal I'd floated a couple meetings ago that I'd like to revisit in the interest of nudging the process towards openness where possible:
This would maintain the confidentiality of individual member organizations' positions, which I hope addresses concerns raised about positions being taken out of context.
There was also a question raised about whether this is worth the trouble for the Interop team to report. I don't think there's much work involved since we will need to compute these totals anyway as part of the process, but nevertheless I think that concern is addressed by making the sharing of this info an option for members rather than an obligation of the Interop team.
Thoughts?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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).
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.