-
Notifications
You must be signed in to change notification settings - Fork 10
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
Should Identity and Actions be in separate repos? #38
Comments
This is the compromise we reached. I can open a separate issue suggesting Identity and Actions be in a single document, if it's not clear how unproductive this is.
I'd like to think people care about solutions to problems, and I don't presume people only care about one or the other. To respect our compromise, we should probably discuss structural categorization at editors' calls in the future before taking action. I believe we already prefer discussing new labels before introducing them, unless it's a precedent copied from another WG repo. I see no reason to enforce a strict "[Identity] *" / "[Actions] *" naming scheme and Lots of specs contain multiple interfaces, yet we don't see e.g. I agree that some pre-existing issues required clarification, like: ...but in other cases it's clearly redundant: Let's close this issue, and work as agreed. |
Indeed, it was the compromise. But it was quite explicitly non-final. It was explicit that the future could see the documents merged (your wish), the repo separated (my wish), or the status quo maintained. It is natural that I wish to convince the group, you included, that we should move in my preferred direction. (Note that this issue is not presented as a blocker for anything. And I doubt it will ever be a blocker.)
If you still believe this is desirable, then you should! (And I hope you will likewise see that issue as non-blocking.)
I did not expect these to be controversial. I want us to employ these labels because they help prevent confusion. For example, if I file an issue about Actions, I don't need to worry that someone might misunderstand that issue as lack of consensus about Identity. And vice versa. I believe clarity is always desirable. What's your reason opposing labelling?
Let's work as agreed while still trying to convince the group of those matters we believe to be relevant. These discussions can be carried out in parallel, politely and productively. |
I'm saying:
I'd like to remove the naming scheme asap, to avoid confusion about whether people need to follow it when filing new issues. If we can't figure out from the issue which APIs it applies to, there's a chance it applies to both, even if the person filing it may be unaware of it. This already happened with #10 and #11 (if we entertain changing configured actions) This seems especially true for feature enhancements, or complaints over a feature falling short of a use case need. |
I agree the labels are useful to track outstanding issues for the sake of progressing the docs in the w3c process. |
Sure. You seem to prefer -labels- over [prefixes]. Let's go ahead with those. Please either remove the [prefixes], or give me your blessing to do so myself. |
Circling back here, I see you've applied a thumbs-up emoji to my previous message. FYI that these do not produce an email notification and are therefore hard to discover. They make up for it by being easy to misinterpret. :-) Would you like me to remove the [prefixes], @jan-ivar? |
Capture Handle Identity has shipped in Chrome (102) and is seeing several millions of uses per week. Meanwhile, the specification of Actions has not progressed. I am genuinely interested in seeing Actions move forward, and fast. I propose that we consider again the separation of Actions into its own repo, where there will be a clear separation of issues (e.g. issue #65), and where less time would be spent on integrating Actions prose with Identity prose. Wdyt? |
It looks like all open issues fall squarely into either the Actions or Identity categories. I've gone ahead and labelled them as much, to make it easier for people to find the issues they care about. But the question should be asked again - should these two documents really share a repo? What are the benefits?
The text was updated successfully, but these errors were encountered: