See also: IRC log
<scribe> scribe: manu
Ian: Thanks all for feedback
<Ian> https://github.com/w3c/webpayments/wiki/CFC_20140412
Ian: The summary can be found at
the link above.
... Based on the feedback, the Chair decision is to publish 3
of the 4 drafts, all but the architecture document.
... There will be an email to make that easy to find in the
mailing list archives. We have lots of responses, strong
support for 3 of the 4 specs. We'll continue to improve the
architecture document.
... We'll return to the publication request once we have more
support.
<dlongley> manu: What's the publication date?
Ian: We request that the director approve the transition to FPWD of the 3 docs - we'll request publication for April 21st.
<Ian> https://www.w3.org/2016/03/15-wpwg-blog.txt
<Ian> IJ will update the blog post to appear on w3.org/payments/WG
Ian: We have this blog post for update - linked from that is the FAQ
<Ian> https://github.com/w3c/webpayments/wiki/PaymentRequestFAQ
Ian: I'd like to understand whether there are any objections for publishing this FAQ w/ specs and blog post notice based on final list of specifications. I'll do that.
<Zakim> ShaneM, you wanted to ask about future updates?
Shane: Do we have a plan going forward for how stuff is rev'd over time?
Ian: The next agenda item
discusses that.
... There is a separate topic that we'll cover over the next
few weeks - what are the next things that will come to our
Agenda. Three proposals, another one on messaging, reorganizing
the documents, so there are no current plans for architecture,
proposals on how to improve it.
... I hear no objections for publishing FAQ to mitigate
concerns raised.
... Congratulations to everyone on the first drafts, still more
to do, but a valuable milestone.
Ian: Mike, are you here?
... Since Mike is not here and it's very late in Tokyo -
assuming he couldn't make it, I'll try to cover this.
... The high-level observation moving forward, once we've
passed monolithic requirement for pushing spec, we can make
finer grained updates henceforth. W3C has an automated
publishing process to push finer grain updates.
... Today we make it clear that the document doesn't reflect
group consensus, the more we push changes that reflect group
consensus, the greater the overall consensus on the spec. So,
how do we push information?
<Ian> https://github.com/w3c/webpayments/wiki/CFC_20140412
<Ian> https://lists.w3.org/Archives/Public/public-payments-wg/2016Apr/0012.html
<Ian> w3.org/TR/
Ian: The question is how do we
get proposals, consensus for those proposals, and then
mechanics for updating editor's draft, and then published
version in TR space.
... The text in the agenda says - how do we get proposed
changes? Since we're using Github, the recommended way for
people is to fork the spec, make changes, then submit pull
requests..
<Ian> PROPOSAL TO THE GROUP:
<Ian> The WPWG will use the auto-publish mechanism
<Ian> Adopt decision policy above (Editors can merge proposals with consensus + editorial; others discussed before decision)
<Ian> Adopt publish-TR-on-merge policy.
<Ian> Create a twitter account to build community around the specs (and inform them of key publications)
Ian: So, how do we make progress
- where should there be friction to ensure consensus, where
should we free up editors?
... We have the tools available to push the Editor's Draft to
the TR page automatically as soon as Editor's make commit to
Editor's draft. It's mirrored into formal publication space.
The W3C has moved into this direction of frequent updates to
published document because we don't want them to be stale. In
the future we'll want stable snapshots.
... We'll want to push those changes to TR space, which ones
get pushed - the Editor's are empowered to merge proposals
where there is consensus - or proposals that fix bugs or are
editorial. The way consensus is measured - there is explicit
decision from Chairs, or obvious consensus in issue
tracker.
... Obvious consensus - strong support and no objection.
... three or four people say it's a good idea, no one opposes,
we're trying to make life easier on editor's. Where there are
challenging topics, bring it to WG agenda - ideally those
discussions are about concrete proposals. It doesn't mean that
in every case. Adopt that decision policy - we publish TR specs
when editor's when they merge PRs.
<Zakim> AdrianHB, you wanted to ask how the editors decide if there is consensus? There are a few PRs that have only supportive comments but have not yet been merged or commented on by
<zkoch> I can respond
<zkoch> as editor
zkoch: I think we have a few PRs waiting to be merged - they're assigned to different editor's - I know I have two assigned, we're actively triaging ones that have obvious consensus.
Ian: A thing that the editor's can do - if they can concretely help synthesize the issues, bring them to the attention of the Chairs that make sense for how the spec should evolve.
<AdrianHB> I am concerned about the rate of progress and feedback from editors (i.e. a signal that says "we're looking at this would be useful")
Ian: There's not action item here
- way that the editor's help the group make progress
... Any feedback on transparency on what editor's are doing w/o
being a burden?
<AdrianHB> I think we should wait for Thursday call each week before we discuss PRs. Right now it feels like PR's go into a black hole
<AdrianHB> I DON'T THINK we should wait
zkoch: We're in a weird transition point, how we deal w/ PRs about that - we met last week to figure out our process. We can talk about what we're comfortable w/ as editor's. We have other full time jobs so we block off time to work on these things. I think we can bring this up w/ other editors on how we communicate this.
<Zakim> manu, you wanted to refine "obvious consensus"
<Ian> manu: Regarding "obvious consensus"...
<Ian> ...I think the definition (strong support, no objections) is ok at a high level
<Ian> ...but I'm concerned because we don't have a lot of people engaging on the issue tracker
<AdrianHB> +1 - wanted to add that there is a responsibility on the group here too to provide feedback
<Ian> ...frequently at W3C a core contingent deals with the spec day-to-day
<AdrianHB> merge decisions are much easier for editors if the group provides some +1s
<Ian> ...I am ok with 3-4 +1's with no objections....but that doesn't mean that it "clearly reflects consensus"
<Ian> ...what about a policy where we don't push specs until people have a chance to review and give their consensus views
<Ian> ...does anybody else share this concern?
<Zakim> Ian, you wanted to mention link to Arch spec as editor draft
Ian: We will have to adjust references to architecture document - those will still exist as editor's draft - is that straightforward, not time consuming.
zkoch: Yes, we should be able to do that.
<VincentK> quit
<Ian> zkoch: I am reluctant to merge pull requests where we have a sense that people didn't have a chance to comment.
zkoch: I tend to agree, there are more active people - some people might be out. I don't think editor's would want to merge things w/ only a few people participating.
<Ian> ...I think the Editors also have a sense that for big issues discussion would be necessary
zkoch: For example, merging multiple arguments into single argument in payment request - I don't think we'd pull that in w/o discussion on call.
Ian: Controversial issues where there is no clear agreement, that doesn't have consensus. The editor's will act in good faith - if decision is necessary - ask the group - that's a great way to work - trust the editor's to make progress, knowing that people can , after the fact, ask that things be removed. Over time things may change and opinions may change and we can always come back.
<Ian> IJ: +1 to editor judgment
zkoch: I think the key thing here is that Editor's will be using their best judgement.
<AdrianHB> I think the editors should set some expectations for the group around how long they expect it to take for a PR to be merged. If the editors see a PR that they think is going to take a while to assess we need a mechanism to signal this to the group
Ian: Also that there are multiple editor's helps. Staff and Chairs can be called on as well - that should help.
<Zakim> ShaneM, you wanted to talk about periodic consensus review and date space and to ask if we could have somone from another group that has done this before come in and talk about the
<zkoch> Adrian: Yeah, I mentioned that I would take this back to the editors about how to provide more transparency around PRs we’re looking at/considering
Shane: Manu mentioned that we do periodic reviews to signal real consensus - even if we're doing frequest TR space updating - when that happens, those documents go into date space - they get a dated version - so the history is there, we can pick one of those and say "this is a point where we want you to do a consensus review".
<AdrianHB> ZKoch: I think an "Under Review" label or similar would be useful with maybe a milestone that indicates when it will be discussed
Shane: That's a way to do that that doesn't churn underneath the people doing the review. I feel like we're having a conversation that many other WG's have. There must be experience in other WGs, can we talk to those WGs?
Ian: Even if other groups have solved this problem, we want to walk though this w/ this group.
<AdrianHB> +1
<AdrianHB> (to Manu)
<MattS> +1
<ShaneM> +1 to manu
<AdrianHB> I think the issue under discussion is not about publication process anyway it's about merge process
Ian: From time to time - we may
be able to do consensus blessing - not sure if that is okay. We
may do it gradually, we may also get group consensus. When we
advance to CR, that's the real decision.
... We could contemplate other proposals, but the one we have
on the table reflects the opinion of a number of folks in
W3C.
<Ian> Manu: I haven't heard anything that scares me.
<Ian> PROPOSAL TO THE GROUP:
<Ian> The WPWG will use the auto-publish mechanism
<Ian> Adopt decision policy above (Editors can merge proposals with consensus + editorial; others discussed before decision)
<Ian> Adopt publish-TR-on-merge policy.
+1
<dezell> +1
<zkoch> +1
<AdrianHB> I propose that we continue to use gh-pages branch for editors drafts and create a new branch that is exclusively used for auto-publishing to TR space
<dlongley> +1
manu: +1
<rouslan> +1
<maheshk> +1
<AdrianHB> +1
<MattS> +1
<CyrilV> +1
<ShaneM> +1
<Ian> SO RESOLVED
<zkoch> :|
<Zakim> manu, you wanted to move to adopt the proposal and move on (we can always change it if it doesn't work out)
<Ian> https://github.com/w3c/webpayments/wiki/Extensibility_Notes
Ian: I wrote down a compendium of
extensibility - we have talked on a number of occasions about
extensibility and how we imagine the system to be
extensible.
... I don't know if we'll get to any resolutions today - let's
look at topics side-by-side - we may reach a better
understanding about how we'll meet these things in all of their
forms.
... Ultimately, if we can reach consensus on requirements,
it'll make it easier to design specs.
... To introduce this briefly - we have a number of components
in the system, including API itself, different aspects of
extensibility, there are payment apps, payment mediators,
payment method identifiers, I'm happy to look through these
quickly, but what I want to ask people to do, group
participants have write access.
... We may want to make sure that we capture the most important
considerations so we can build the specs accordingly and meet
peoples needs.
... Some of these around payment method identifiers, those are
the four requirements we discussed in San Francisco. Those
appear in FPWD.
... Those may look the most familiar - for payment apps, we
have talked about the need for mediators to communicate w/
payment apps. We have talked about the update problem (if I
update my payment app and register a new instrument, mediators
need to be aware of that). We've also talked about whether
mediators should expose registration information w/ other
mediators.
... There are some open issues about the need to support custom
data for different payment methods. We have talked about
payment mediator extensibility - should we be able to have
different payment mediators.
... Matt suggested mediator role - here I've indicated that a
browser not support 3rd party mediator functionality as far as
browser expectations - payment applications can fill that role.
Interoperability to swap in different mediators - 3rd party
payment apps should provide those choices.
... Real quick walkthrough - I'm not looking for consensus on
requirements. We want to make sure it includes requirements
that people have.
MattS: Because this is a wiki, I
wonder if we should be editing it or raising issues? Then
update the document?
... We don't have PRs to moderate this.
Ian: For a while, people can add
to the document just to flesh it out
... That's not what we'd claim consensus on, though... once we
have a draft, freeze it, then discuss that
... This is just a prompt to get people to contribute to
it.
MattS: Ok, append-only to wiki
Ian: I like it when people put
down notes - like "I disagree for reason X"
... Asynchronous collaborative editing.
... We could ask for people to make changes to this by April
21st, then we can start to look at consensus.
<Ian> Manu: General +1 for the approach I think.
<Ian> ...I feel like we've labeled a lot of things under the extensibility banner that may not be extensibility topics.
<Ian> ...one is around functionality detection
<Ian> ..can we identify the extensibility chunks and then focus on that one.
<Ian> ...e.g., message extensibility with a concrete proposal
Ian: I put them in the same document because we use extensibility to mean "all of them"
<MattS> and I also lablled issues associated "Extensibility/Verisoning"
Ian: If you're saying "Can we
prioritize?" I'm fine with that.
... Sounded like I wanted a decision after 21st, that may not
be desirable/achievable - want to prompt people to contribute
with a timeline of a week.
... If people want to focus on a specific spec, then that's
fine too - but there are multiple extensbility topics so we're
not talking past one another.
... So, if you have extensibility in one place, you MAY not
need it as much in another.
... One thing that would be really nice is to get commitments
from people to review this - we feel more confident when we
know if multiple people have looked at this.
<MattS> I will
<Ian> ACTION: MattS to review the extensibility wiki by 21 April [recorded in http://www.w3.org/2016/04/14-wpwg-minutes.html#action01]
<trackbot> Error finding 'MattS'. You can review and register nicknames at <http://www.w3.org/Payments/WG/track/users>.
<ShaneM> I will too
<scribe> ACTION: Manu to review extensibility wiki by April 20th. [recorded in http://www.w3.org/2016/04/14-wpwg-minutes.html#action03]
<trackbot> Created ACTION-18 - Review extensibility wiki by april 20th. [on Manu Sporny - due 2016-04-21].
Ian: That's the extensibility topic - the goal is to have consensus to guide the next steps there.
<Ian> No update!
Ian: My understanding is that
we're getting close to talk about Blockchain workshop - Nick
has been traveling, no updates really - apologies for
that.
... We'll try to work w/ this group for ideal scheduling,
whether it's with or in parallel.
Doug: There has been a little bit
of backchannel discussion on this - sorry for the conflicts -
we're going ahead w/ the workshop at MIT at end of June. There
is a question on whether or not MIT could also host
face-to-face meeting. It may be possible. There would be some
costs that would have to be covered, we think we could get the
rooms.
... If people are interested in attending both things and want
to come to Boston to do that, want to know who is interested in
co-located thing?
MANU IS VERY INTERESTED IN CO-LOCATING WPWG F2F and BLOCKCHAIN WORKSHOP
Doug: Hope that some of you are interested in Blockchain workshop, let us know if you are.
MattS: Have you had a chat w/ WorldPay on that - wait on that before you make a formal proposal to the group.
<MattS> Im a +1 for that then!
Doug: Nick suggested that we may
want to host in Boston - we haven't had a chance to talk
yet
... I don't want to conflict w/ whatever he has going forward
there.
MattS: If Nick's happy w/ Boston, I'm happy w/ Boston.
Doug: I've been chatting with him on it. Apologies that we don't have more information on it - working hard to get this information to you.
Ian: We will know more next week.
Doug: If you're interested in attending, let us know - who is interested in attending, what right course is going forward, etc.
<AdrianHB> In lieu of being able to discuss PR 133 would appreciate feedback from the editors on the PR as it addresses a lot of issues
<Ian> https://github.com/w3c/browser-payment-api/pull/133
Ian: Now that we've gotten
through FPWD, I expect WG's agenda to become more focused on
issues. One of the things that stood out for me was Adrian has
put together a proposal - PR133 - addresses 4 open
issues.
... That's noteworthy enough that we should discuss in the
group - notably, what do the editor's thing? No changes happen
before FPWD, but this is for subsequent edits.
... Do the editor's have any feedback on this?
<zkoch> looking
<Ian> zkoch: Not yet
zkoch: We haven't had a chance to look at it in depth - will do so tomorrow.
<ShaneM> ACTION: ShaneM to review the extensibility wiki by 21 April [recorded in http://www.w3.org/2016/04/14-wpwg-minutes.html#action05]
<trackbot> Created ACTION-19 - Review the extensibility wiki by 21 april [on Shane McCarron - due 2016-04-21].
Ian: We urge others to take a look at that proposal - that's a helpful way to make progress rapidly.
<AdrianHB> Wants to re-emphasize that the group needs to GET INVOLVED! Even just a +1 or -1 helps us understand the general feeling
<zkoch> Yep
<zkoch> :)
Ian: Zach may be saying - let's not do detailed issues yet until we've given editor's some breathing space.
manu: +1 to AdrianHB - more people need to start weighing in.
<AdrianHB> I propose we dedicate next week to issue resolution
Ian: We want people to make
proposals - Cyril wrote up a draft around SEPA, I've been
reaching out to other participants in the group as well.
... General request to the group to do payment method specs.
People may not be comfortable using Github - open question, do
we need to be using WebIDL?
... Do people want tutorials on WebIDL, ReSpec, Github, put
stuff into a form that's consumable by the group? We can find
people to help w/ that.
<Ian> Manu: Sending comments by email is fine, too.
<Ian> IJ: Agreed. This is an invitation to get people more into github
Ian: If you do want to do the more authorly things - but feel there are technology barriers, we can help - let us know.
<Mike5> e-mail is a barrier to some people actually
<MattS> Also, there is some confusion about how easy it is to use GitHub, so understanding how to use the Web UI rather than GitHub Desktop or Shell
<MattS> in terms of reducing technology, not knowledge barrier!
<Mike5> some contributors really dislike dealing with our old-school mailing-list culture
Ian: Doug has proposed a publicly consumable quarterly report...
manu: Mike5 - yes, but some people don't know how to use ReSpec, Github, etc and don't have time to learn it - but they do know email... I'm just suggesting we take input any way we can.
Ian: We want to see if there are signs of interest for regular updates - snapshots are nice.
<zkoch> +1 to taking input the way we can
Ian: Next meeting is 21st of
April - we'll be discussing whether to take up three proposals
in this week's agenda.
... Come to the meeting informed.
<AdrianHB> Thanks
<zkoch> seeya!
<Ian> scribe: Manu
<Ian> The WPWG will use the auto-publish mechanism
<Ian> Adopt decision policy above (Editors can merge proposals with consensus + editorial; others discussed before decision)
<Ian> Adopt publish-TR-on-merge policy.