-
Notifications
You must be signed in to change notification settings - Fork 62
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
What are the WPWG February 2016 face-to-face prioritized issues #89
Comments
Here is my prioritized list of questions that probably need to be answered for us to get to a March 2016 FPWD goal: Technical
Strategic
Operational
|
Thanks @msporny. @mattsaxon started documenting "Differences between the proposals" a while back on the wiki, which wasn't a bad basis for coming up with some good discussion material for the face-to-face. What do you think of using the issue tracker to capture these in the same way we have been doing for calls? There is already a "Resolve at F2F" milestone? We can use this thread to brainstorm but when there is a concrete proposal let's capture it as such and allow the group to discuss it. On that note, are there any of our existing proposals/questions that we should tag for the F2F? |
I mean to link to the wiki page: https://github.com/w3c/webpayments/wiki/Issue-Summary |
Thanks for writing up your list. (I also hope Adrian Bateman and/or Zach do so.) Here are a few comments.
That's a good question. For the moment, I'm not sure which use cases
I don't think "what if we get something wrong" is a question we
Registration is in scope of our charter. We have not discussed much
That question sounds like a reference to the HTTP API. Right now there is no question we will do an HTTP API per our charter. We've postponed expectations about FPWD until 1 June. Is there something new in your question?
I'm not sure to understand the question.
Agree that's an important question.
That's a reasonable question (per my comment above that I'm not
I propose these questions instead:
I'm not sure what that question means. It depends on the question about
Personally, I hope that we make a WG decision to take up the work as of the end of the FTF meeting. Our decision will affect who the editors will be. |
I think this is a good question but will be implicitly answered by this:
There is a strong desire from the browser vendors to "streamline the checkout experience" including gathering shipping data. (Please keep me honest here @adrianba, @zkoch, @bifurcation, @nickjshearer, @haavardmolland) The goals in our charter go beyond this which suggests other flows are needed for other use cases or a low level payment API is needed that can be used to compose other flows. The paymentRequest API takes a different approach to the checkout API on how these two functions are exposed and we should decide which we like most.
+1 - We need to start defining this. The CG proposal does address registration but I think we need to answer the following question before we can tackle registration:
Which you partly address in the question:
I also think we need to decide if there is such a thing as a Web-based payment app or if we're advocating for something like a sandboxed ServiceWorker? Hence the broader question above.
I think we're making good progress on this in the list but don't believe we can close this till we've tried to implement the UI and understood the constraints properly. To my mind there is still too much hand waving about flow of control and inter-dependancies between steps.
We should consider this in the finer details of the design. The flexibility that the checkout API offers is my preference but we need to consider situations where a call like
Editors chosen and WG spec in a W3C repo soon after the face to face would be my hope.
Are there transparency issues? There's no restriction on people have sidebars but any impact those have on the deliverables need to still be made via a proposal that gets group consensus. Think this will be related to the choice of editors and work process we define for the specs.
Don't think we should tackle this at the F2F. It's a topic for the AC. |
I would like to add either to the agenda or as an issue the following; Adoption/Transition of the API |
That is correct. |
Instead of versioning, I would prefer feature detection. For example: if (checkout.supports('billingAddress')) {
checkout.request('billingAddress');
} or: if (checkout.requestBillingAddress) {
checkout.requestBillingAddress();
} |
+1, although I don't have the time to triage, unfortunately. I was just trying to set this issue up as a big dumping ground for prioritized issues that are important for folks - it's up to the chairs/staff to organize them into something they think would be the most efficient wrt. making progress.
I did a scan through them and there is some overlap here and there. I'll try to do another scan before the F2F, but honestly almost every hour of my awake time is allocated from now until the face-to-face. |
I think Manu has hit on most of the key questions that will need to be addressed. My hope is that we address what I see as the core issue as soon in the FTF as possible: What API direction are we going to move forward with? There are a bunch of interesting architectural questions that have been brought up (promises, events, etc) that I think are much easier discussed in person with a whiteboard handy, but are only possible if we find agreement on a fundamental API direction. I'm slightly less concerned with the operational issues Manu mentioned, not because I don't think they're important, but because they're easier addressed via phone calls and email. I'd rather spend the face time discussing the more nuanced issues. |
I think we need to discuss (though I personally won't be present): What are the goals of the APIs? I think we have at least two separate goals:
|
@dlongley, I think that both of your goals can be achieved in a single API. |
Same for me - I guess I don't see why those goals are necessarily separate. They seem intertwined, without Goal 1 it is difficult to implement Goal 2, and without Goal 2 there is less incentive to implement Goal 1. I agree with Zach that we should resolve the approach and pick one, rather than keep going down two paths. |
I think it's possible as well. But there is a question of whether or not we should solve it that way. And that (at least partially) has to do with whether we should create a high-level API that is composed of lower-level APIs or just one high-level API that has flags to turn things off/on. With lower-level APIs (or at least that design in mind), there is more room for merchants to access new things in the Web Platform using flows that work for them (potentially more innovation and broader adoption/reuse). If we do a high-level API without a composable design in mind, and it ends up only working for some people, we may end up having to redo a lot of work in the future in order to create something that works for everyone else. |
@dlongley our charter has this to say on our goals:
@msporny - with regard to registration of payment instruments, we are chartered to deliver this capability so you are absolutely right to raise the issue - because I don't think we've made much progress in this regard |
Yeah, and I think the proposed APIs/specs we have so far are touching on those goals. The Checkout API puts an emphasis on the first two and the Web Payments Browser API (and HTTP and Messaging specs) emphasize the last two, including having an eye on extensible, machine-readable semantics. |
Yes, there are transparency issues with the W3C staff and the Chairs of the Web Payments WG. You probably don't see it because you have access to all the information. The rest of us don't. To be clear, I don't think it's being done insidiously, but having been at the receiving end of it, it will be harmful to the group if it continues. There have been multiple times I've observed where the Staff (with the aid of the Chairs at times) execute on a plan citing "data gathered from people that we've talked to" without giving the editors a heads up or making it clear who those people are or what they said. To provide one example, the discussion in the Extensibility thread (#27) was disheartening. The way JSON-LD was sidelined by a Chair and Staff Contact without significant WG discussion felt premeditated. Here are a few of the issues with that thread (and discussion around it):
I think there is a lot of strategy discussion happening during the Chairs/Staff call and much of that thinking isn't being conveyed to the group before the chairs and staff start acting on it. It also feels like the staff is representing the viewpoints (or perceived viewpoints) of W3C members instead of asking those W3C members to speak for themselves in the group. I'll also note that I've participated in several groups where instead of having weekly Chairs/Staff strategy calls, the Chairs just thought out loud via the mailing list and everything worked just fine (because the group knew what they were thinking). I don't like that we have no idea about what goes on in the Chairs/staff calls (primarily because there is no summary or visibility into those conversations). In addition, our group has 68 individuals, only 3 of which are invited experts. I know we've taken 100+ days to get back to a very well qualified Invited Expert and I'm wondering how many more have applied but been rejected or are still waiting for responses? We also just rejected someone who has been an active W3C spec editor/contributor from attending the face-to-face to prioritize potential new W3C members attending. I can't quite put my finger on it, but all of these things are adding up. This is one of the most closed, non-transparent W3C WGs I've been involved in in a while, and I can think of a few things we could do to make it more transparent:
|
Sorry to disagree, but I'm not sure that quote can be taken to imply any kind of preference. I could ask you what changes would be necessary to your proposal to support shipping, but that wouldn't mean I favoured it. I think you might be inferring something that isn't there. It is probably better if the rest of your points are addressed by the chairs, but I will say that if you're going to raise the issue then I think it's only fair that I point out both yourself and David seem to be doing work over at http://spec-ops.io that would have impact here but hasn't been raised or discussed in the WG or IG. It seems a little strange to bring up transparency whilst creating an entirely separate organization with a chair of the IG that lists web payments work under its remit. Of course, those efforts may well be very worth while...it's just I don't know anything about them. |
@msporny re: Transparency
As such, I don't believe there is a transparency issue in this group but I think we should discuss this further at the F2F. |
Creating an organization to help us do our work here that is being publicly announced prior to doing any of said work is not a transparency issue. This is: Person A tells Person B that "everyone" wants them to do something and that "everyone" thinks they are being intransigent because they haven't done so yet. Person B has no idea who "everyone" is and is aware of little to no discussion on the matter other than perhaps with Person A. Person B also had no idea that there was, supposedly, a long lasting push to make them do this thing. That level of unawareness on the part of Person B because there is no public record or discussion substantiating the claims made by Person A is a lack of transparency. It shouldn't happen because it causes peoples' positions, demeanors, and motivations to be misrepresented. Ideally, when people have opinions they would speak for themselves and make those things known in a public way. If you must speak for another group, please avoid saying "everyone" and be more specific. All of this can happen on the issue tracker, or preferably, in my view, on the calls so that there can be more high-bandwidth open discussion of it. |
This is a specious argument. I don't know how much you know about elections in the United States, but there are two stages. In the first stage, (typically wealthy) campaign donors pick the candidates. In the second stage, those candidates are presented as the only viable options to the people. So, as the supporters of this system say, all that matters is the people pick the final winner. Let's be careful that we don't emulate that system. It's not a good one. Now, that doesn't mean we can't have side discussions and come up with proposals that we think the group will be amenable to. It just means that it's important that the group be more informed and engaged in the entirety of the decision making process. I think most of the problems thus far have had to do with the fact that we don't have a set of specs that we're all working on as a group, together. This includes discussing the details of them on the calls. Part of this will require us making sure our goals are clear and in alignment. I'm hopeful a lot of this will be resolved following the F2F and there won't be a sense of different groups of people working in two different directions and then presenting two things for people to pick from. We could probably come up with something together that worked better for everyone. |
@nickjshearer wrote:
That's a fair point. The only reason I'm inferring is because there are a number of other items that have raised red flags for me and I'm trying to see if they raised red flags for anyone else.
We've been asked by folks at W3C (in their personal capacity) to not talk about Spec Ops yet. The effort doesn't officially launch until Monday, so there's no "there" there yet. That said, it's not a secret and we'd be happy to discuss how we're trying to help the group w/ funded editors, test writers, and open source implementers during breaks or dinners (non face-to-face time) |
I learned about Spec Ops through this thread. |
@adrianhopebailie wrote:
I normally wouldn't care about what the Chairs and Staff discuss wrt. getting consensus in the group. My concern is that you've overstepped the "getting consensus" remit that Chairs/Staff have by arguing directly for certain things to happen based on input you've gathered from others, without sharing that input with the group, and then not waiting for the WG to come up to speed before pushing a proposal forward.
+1, that's totally fine. Not reporting what you find back to the group in a public way is the thing that I find concerning. We felt side-swiped by the way issue #27 (and the CG specs to a certain degree) was handled.
Input from an unknown number of people we don't know is not useful data for the group to analyze. When I've chaired, I've endeavored to have those people bring their input to the group and I've found that in many of the cases, they're fine with publishing their thoughts and engaging the group.
It's fine if you collect data and then come back and present technical arguments to the group, but I don't really think that happened in this particular case, and I'm concerned about it not happening again. I also find it surprising that most everyone that you talked to about JSON-LD didn't want to make a single public comment about it.
Could you provide the link to where this happened?
I thought you said Ian was going to talk to the W3C Team about the specs?
I'm fine w/ those discussions happening as long as they're made public before you start taking action on the strategy. What I feel has happened a few times is that the chairs/staff are discussing strategy in their meetings, making a decision on the direction to go, and then plowing in that direction.
I have no problem with this general strategy, what I think is missing is:
+1, no problem with this, but make it clear that you're doing that.
I didn't let the group know about the call w/ Zach/Rouslan. I did let the group know that we were going to do a similar call w/ AdrianB. After we had those calls, we let the group know as well as what we talked about and who said what. Sidebar conversations are fine. What is not fine are sidebar conversations between the Chairs/Staff that result in data gathering and a strategic discussion being made and then executed upon without filling the group in on the data (in detail), or the strategy and why we're executing upon it. This is even more concerning when the Staff starts aggressively pushing for a decision to be made (issue #27) while there are people stating that they don't think the WG is up to speed on the particular issue yet.
I went out of my way to state that I did not believe the sidebars were malicious (because I don't think they were). I'm going to do it again - I don't think they were malicious, but they were not followed up on properly by the chairs/staff.
The Chairs and Staff are there to seek consensus among the group. You are also held to a higher standard to ensure the group is operating transparently and with all of the information in front of them.
I've accused Bitcoin companies of not participating. I think there may still be a chance to pull some interesting Invited Experts we could pull from the Bitcoin community. I just haven't attempted to do that because it doesn't seem like the Chairs/Staff/W3C are interested in persuing Invited Experts (and they're the ones that tend to have the final say on IEs). What I'm trying to do is to raise this issue before it gets worse, and to see if anyone else in the group feels the same way. If not, it'll be a very quick conversation and we'll move on. Also note that I don't want this to take up a lot of time at the face-to-face and I'd prefer if it were at the tail end of the agenda. Again, I don't think this transparency stuff was intentional or malicious. Each of you have done a fine job in the /many/ other aspects of Chairing/Staffing. Having been in the same position as you before, I know how hard it can be to strike the right balance. |
@ianbjacobs wrote:
|
Closing this issue as the face-to-face has happened and we touched on most of these points (sans the Transparency issue). |
This is an attempt to come up with a prioritized set of issues for the upcoming WPWG February 2016 face-to-face. The goal is to focus on issues that will get the group to a FPWD of the browser APIs by the end of March 2016.
Please list the issues, in priority order, that you feel are most important for the group to reach the March 2016 FPWD goal. The authors/editors of the Browser API specifications (@zkoch, @adrianba, @dlongley, @msporny) should certainly chime in as should any WG member that feels strongly about the issues that need to be dealt with to reach the March 2016 FPWD goal.
The text was updated successfully, but these errors were encountered: