What are the WPWG February 2016 face-to-face prioritized issues

[msporny]

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.

[msporny]

Here is my prioritized list of questions that probably need to be answered for us to get to a March 2016 FPWD goal:

Technical

1. Are we doing a high-level API (Checkout) AND a low-level API (Payment)? Or just a high-level API (Checkout)?
2. What if we get the Checkout API wrong? Should we specify APIs to get shipping address, request payment, and polyfill the rest until we can figure out the best way to do it?
3. Are we going to support "payment app" registration via the API or is it going to remain unspecified?
4. How are Web-based payment apps going to receive a payment request and respond with a payment acknowledgement?
5. What are the combinatorial issues with adding the ability to "get more payer information" to the Checkout API?
6. Is the interaction pattern for the Checkout API going to be promises, events, or a hybrid? How does one request payer information (like shipping option) when processing a shipping address change option.

Strategic

1. What are the goals of the Checkout API? What are the goals of the Payment API? Are they different?
2. What data do we have to study in order to see if the APIs will meet their goals?
3. How does one extend the type of information you can ask for via the Checkout API? For example, is a WG required to add a Billing Address request to the API?

Operational

1. Who are the editors of the WG specs going to be and when are we putting the specs into the WG repo?
2. How are we going to fix the transparency issues and backchannel discussions in the group?
3. Is the "incubate the specs in a CG" model working?

[adrianhopebailie]

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?

[adrianhopebailie]

I mean to link to the wiki page: https://github.com/w3c/webpayments/wiki/Issue-Summary I changed it from a comparison of the proposals to a high level issue summary. I was capturing the various proposals and for and against shipping address capture which provides an idea of the format I was experimenting with.

[ianbjacobs]

@msporny,

Thanks for writing up your list. (I also hope Adrian Bateman and/or Zach do so.) Here are a few comments.

Technical

Are we doing a high-level API (Checkout) AND a low-level API (Payment)? Or just a high-level API (Checkout)?

That's a good question. For the moment, I'm not sure which use cases in our current charter require the checkout API. There is a smaller question of whether shipping address should be in or out of the payment API. But after shipping address, what are the topics in scope for our charter that the checkout API would cover?

What if we get the Checkout API wrong? Should we specify APIs to get shipping address, request payment, and polyfill the rest until we can figure out the best way to do it?

I don't think "what if we get something wrong" is a question we need to focus on. I do agree there is a question of whether shipping addres is in the payment API.

Are we going to support "payment app" registration via the API or is it going to remain unspecified?

Registration is in scope of our charter. We have not discussed much lately. I agree we need to.

How are Web-based payment apps going to receive a payment request and respond with a payment acknowledgement?

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?

What are the combinatorial issues with adding the ability to "get more payer information" to the Checkout API?

I'm not sure to understand the question.

Is the interaction pattern for the Checkout API going to be promises, events, or a hybrid? How does one request payer information (like shipping option) when processing a shipping address change option.

Agree that's an important question.

Strategic

What are the goals of the Checkout API? What are the goals of the Payment API? Are they different?

That's a reasonable question (per my comment above that I'm not sure yet what the goals of the Checkout API are).

What data do we have to study in order to see if the APIs will meet their goals?

I propose these questions instead:

• What criteria will we use to make decisions about API direction? (cf our agenda for some)
• How will we get implementation experience?

How does one extend the type of information you can ask for via the Checkout API? For example, is a WG required to add a Billing Address request to the API?

I'm not sure what that question means. It depends on the question about goals for that API (and also what's in scope for this WG).

Operational

Who are the editors of the WG specs going to be and when are we putting the specs into the WG repo?

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.

[adrianhopebailie]

• Are we doing a high-level API (Checkout) AND a low-level API (Payment)? Or just a high-level API (Checkout)?

I think this is a good question but will be implicitly answered by this:

• What are the goals of the Checkout API? What are the goals of the Payment API? Are they different?

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.

• Are we going to support "payment app" registration via the API or is it going to remain unspecified?

+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:

• How will payment apps be implemented?

Which you partly address in the question:

• How are Web-based payment apps going to receive a payment request and respond with a payment acknowledgement?

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.

• Is the interaction pattern for the Checkout API going to be promises, events, or a hybrid? How does one request payer information (like shipping option) when processing a shipping address change option.

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.

• How does one extend the type of information you can ask for via the Checkout API? For example, is a WG required to add a Billing Address request to the API?

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 request('billingAddress') may be made in future in a browser that only supports returning the shipping address. i.e. Versioning

Who are the editors of the WG specs going to be and when are we putting the specs into the WG repo?

Editors chosen and WG spec in a W3C repo soon after the face to face would be my hope.

How are we going to fix the transparency issues and backchannel discussions in the group?

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.

Is the "incubate the specs in a CG" model working?

Don't think we should tackle this at the F2F. It's a topic for the AC.

[mattsaxon]

I would like to add either to the agenda or as an issue the following;

Adoption/Transition of the API a. Finding the relevant payment application b. If merchant can prefer one payment app over another if there are multiple apps that can perform the same method b. Fall-back methods when no such app exists (or the shopper doesn't want to sign-up to the terms & conditions) c. What our expectation is for situations where the merchant wants to override the 1.0 implementations to better control the flow

[rsolomakhin]

There is a strong desire from the browser vendors to "streamline the checkout experience" including gathering shipping data. (Please keep me honest here...

That is correct.

[rsolomakhin]

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 request('billingAddress') may be made in future in a browser that only supports returning the shipping address. i.e. Versioning

Instead of versioning, I would prefer feature detection. For example:

if (checkout.supports('billingAddress')) {
  checkout.request('billingAddress');
}

or:

if (checkout.requestBillingAddress) {
  checkout.requestBillingAddress();
}

[msporny]

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?

+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.

On that note, are there any of our existing proposals/questions that we should tag for the F2F?

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.

[zkoch]

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.

[dlongley]

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:

1. Making it possible for users to install Payment Apps and allow merchants to pass extensible payment request messages to them through the user agent to get consent to pay/perform payments. Allow innovation and competition at the end points (outside the user agent) and by payment networks.
2. Improving the checkout experience for common online commerce. Allow innovation and competition by user agents.

[rsolomakhin]

@dlongley, I think that both of your goals can be achieved in a single API.

[nickjshearer]

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.

[dlongley]

@rsolomakhin,

I think that both of your goals can be achieved in a single API.

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.

[mountainhippo]

@dlongley our charter has this to say on our goals:

• A better checkout experience for users, particularly on mobile devices. The standards should facilitate automation, one approach to improving the user experience.
• Streamlined payment flow, which is expected to reduce the percentage of transactions abandoned prior to completion ("shopping cart abandonment").
• Easier adoption of payment instrument improvements (e.g., related to security) or new payment instruments.
• Added value through machine-readable digital payment requests and payment responses.

@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

[dlongley]

@mountainhippo,

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.

[msporny]

Are there transparency issues?

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 (https://github.com/w3c/webpayments/issues/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):

• Presumably there was a W3C Team Review on the API specs (@adrianhopebailie noted something to this effect in a comment somewhere), but none of this review was made available to the group. It seems as if the team review influenced how @adrianhopebailie and @ianbjacobs approached https://github.com/w3c/webpayments/issues/27 but did not let the editor's (or WG) know about the outcome of that review.
• Premature assertion by @ianbjacobs that the Google/Microsoft proposal is what we're going to adopt "Can you tell me what changes would be necessary to the Google/Microsoft proposal to ensure that it does not "forbid" someone from passing JSON-LD?" (https://github.com/w3c/webpayments/issues/27#issuecomment-178652405) - Where was that coming from?
• @ianbjacobs asserting "I don't know JSON-LD well enough." but then fighting pretty hard against its inclusion as anything but an informative reference.
• Presumption by the chairs and staff contact that the Google/Microsoft proposal has "more momentum than the CG specs". I heard at least one of the Chairs and both staff contacts say the same thing in the same way weeks ago, before there was much discussion in the group. This typically happens when there has been a discussion that has happened behind closed doors. I'd like to know how the Chairs and staff contact came to that conclusion, because it was not discussed publicly.

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:

1. The Chairs and staff either minute their weekly meetings or stop having them.
2. If there is a review of specs the group is working on, we hear about it, and directly from the reviewers.
3. If W3C Members have an issue with the specs we're working on, we hear about it, and directly from the W3C member (not filtered through a staff contact).
4. We make an effort to get more than 3 IEs into the group, it's clear to me that we don't have enough perspective on Linked Data, merchant needs, security, Bitcoin, or browser technology in the group. I'm sure there is other stuff we're ignorant of as well. We could use a few more spec editors. Let's fill some of those knowledge / labor gaps by being more inclusive about Invited Experts.
5. We should allocate 20+ slots per face-to-face for observers and pick venues that can accommodate these people. We shouldn't be turning away as many people as we are for this face-to-face. We prioritize who we invite on who might help us first, and who might become a W3C member second (not the other way around, which is how it is right now).

[nickjshearer]

Premature assertion by @ianbjacobs that the Google/Microsoft proposal is what we're going to adopt "Can you tell me what changes would be necessary to the Google/Microsoft proposal to ensure that it does not "forbid" someone from passing JSON-LD?" (#27 (comment)) - Where was that coming from?

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.

[adrianhopebailie]

@msporny re: Transparency

• The staff and chairs have a weekly meeting on a Tuesday to discuss progress and set an agenda for the upcoming call. This is the first request I have seen to have the minutes of that call made public.
• The staff and chairs also regularly reach out to other W3C staff or independent experts for their input on the work so far.
• In doing this outreach we have not always asked for permission to share the source of this input so in the interests of protecting the relations we have with those individuals it is aggregated through the chairs and staff.
• The chairs and staff have used these outside channels to ensure we are well informed in how we deal with topics such as JSON-LD which are being aggressively pursued by members who argue that the only reason their proposals are being opposed is ignorance of the technology.
• There has not been any official W3C Team review of the API proposals and so there is no output to share other than what has been expressed in the open discussions.
• The staff and chairs do discuss strategies we should pursue to deal with issues that we consider blockers to the group's progress. (Unfortunately these issues are often not fundamental but are creating so much noise that they are distracting the group from making progress.)
• These strategies involve a plan to gather as much information as possible on the issue and put it in front of the group and then push the group to make a decision on the way forward.
• Where the discussion is one-sided we attempt to present the other-side of the argument for the benefit of the group and to ensure that when it comes time to resolve the issue the members are well informed.
• There is a lot of discussion that happens outside the group's open channels. I am aware of at least 2 recent direct calls between yourself and other group members that a) did not include either the staff or chairs, b) were not minuted c) the group were only made aware of after the fact.
• I consider these to be useful for efficient issue resolution between the parties, not malicious back-channel discussions. I'm not sure why you consider the discussions initiated by the chairs or staff in a similar vein any different?
• The key is, no matter how much discussion happens directly between members, the chairs or staff, nothing is ever resolved by the group without being presented and discussed openly.
• There has only been one IE application that I am aware of being declined. The individual's application was lost for some time which was a genuine mistake that the staff have apologized for. The application was recently declined on the back of a discussion with the individual who was happy to participate via the mailing list and therefor didn't require IE status anyway.
• You suggest getting IEs from, among others, the Bitcoin community and yet you yourself have publicly accused them of not wanting to be involved. I'm not sure what more you want the chairs and staff to do here?

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.

[dlongley]

@nickjshearer,

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.

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.

[dlongley]

@adrianhopebailie,

The key is, no matter how much discussion happens directly between members, the chairs or staff, nothing is ever resolved by the group without being presented and discussed openly.

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.

[msporny]

@nickjshearer wrote:

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.

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.

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.

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)

[ianbjacobs]

I learned about Spec Ops through this thread. Ian

[msporny]

@adrianhopebailie wrote:

The staff and chairs have a weekly meeting on a Tuesday to discuss progress and set an agenda for the upcoming call. This is the first request I have seen to have the minutes of that call made public.

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.

The staff and chairs also regularly reach out to other W3C staff or independent experts for their input on the work so far.

+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.

In doing this outreach we have not always asked for permission to share the source of this input so in the interests of protecting the relations we have with those individuals it is aggregated through the chairs and staff.

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.

The chairs and staff have used these outside channels to ensure we are well informed in how we deal with topics such as JSON-LD

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.

which are being aggressively pursued by members who argue that the only reason their proposals are being opposed is ignorance of the technology.

Could you provide the link to where this happened?

There has not been any official W3C Team review of the API proposals and so there is no output to share other than what has been expressed in the open discussions.

I thought you said Ian was going to talk to the W3C Team about the specs?

The staff and chairs do discuss strategies we should pursue to deal with issues that we consider blockers to the group's progress. (Unfortunately these issues are often not fundamental but are creating so much noise that they are distracting the group from making progress.)

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.

These strategies involve a plan to gather as much information as possible on the issue and put it in front of the group and then push the group to make a decision on the way forward.

I have no problem with this general strategy, what I think is missing is:

1. When you put it in front of the group, let us know where that information came from or push people to make comments in the issue tracker instead of relaying anonymous tips on the specs. For example, I think it's really helpful that @adrianba got Travis and Jake to take a look at some of the specs and comment publicly. I would expect this to be the norm.
2. When you push the group to make a decision on the way forward, make sure they're participating and the conversation isn't between chairs/staff and just the proposers of a particular spec.

Where the discussion is one-sided we attempt to present the other-side of the argument for the benefit of the group and to ensure that when it comes time to resolve the issue the members are well informed.

+1, no problem with this, but make it clear that you're doing that.

There is a lot of discussion that happens outside the group's open channels. I am aware of at least 2 recent direct calls between yourself and other group members that a) did not include either the staff or chairs, b) were not minuted c) the group were only made aware of after the fact.

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 consider these to be useful for efficient issue resolution between the parties, not malicious back-channel discussions.

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.

I'm not sure why you consider the discussions initiated by the chairs or staff in a similar vein any different?

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.

You suggest getting IEs from, among others, the Bitcoin community and yet you yourself have publicly accused them of not wanting to be involved. I'm not sure what more you want the chairs and staff to do here?

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.

[msporny]

@ianbjacobs wrote:

I learned about Spec Ops through this thread.

• sigh * - We'll put you in touch w/ the W3C folks that know about Spec Ops, and Shane and I will be happy to fill you in on it at some point this week.

[msporny]

Closing this issue as the face-to-face has happened and we touched on most of these points (sans the Transparency issue).