Orie Steele: Since this isn't a formal WG, we should leverage that freedom and work faster, particularly since working fast increases chances of this going standards track later ✪
... aiming for faster PRs, more frequent PRs, and operate under the "UNSTABLE COMMUNITY DRAFT" banner
... merging major changes with positive feedback and 1 or 2 reviews could be merged on day 7 without discussion on call, and minor PRs even faster, is a policy i would support
... I would recommend no PR stay open over a week if there are no changes requested by 2+ reviewers
<orie> yes
Manu Sporny: To clarify, editorial and non-substantive at discretion of editors, for substantive feedback, leave open for 7 or longer if it takes longer to resolve change requests ✪
<orie> PROPOSAL 1: Any editorial PR can be merged as soon as 2 code owners approve the PR.
<orie> PROPOSAL 2: Any none editorial PR can be merged as soon as 2 code owners approve the PR, and its been open without change request for a minimum of 7 days.
PROPOSAL: Any editorial PR can be merged as soon as 2 code owners approve the PR.
RESOLUTION: Any editorial PR can be merged as soon as 2 code owners approve the PR.
PROPOSAL: Any none editorial PR can be merged as soon as 2 code owners approve the PR, and its been open without change request for a minimum of 7 days.
Mike Prorock: +1 Lots of gaming on that kind of thing ✪
Mahmoud Alkhraishi: 7 Days since last change req? ✪
<orie> YES
Manu Sporny: But that opens the door to a lot of gaming ✪
Mahmoud Alkhraishi: Would adding code owners req'd for approval help? ✪
Orie Steele: I don't think that helps, 2 will tag the 3rd if there's a problem ✪
... and besides if our codeowners can't triage this many PRs in a timely manner we can get new ones
... and we should use change request feature in github to be very clear and direct
... even if the change request is "i will not support any form of this PR" (written into the CR window of the GH interface)
Orie Steele: +1 To being early in the game... we should not be processing contributors to death... ✪
Mike Prorock: +1 Joe - it is also pretty easy to go put another PR in to adjust something as needed ✪
Joe Andrieu: I think we should remind ourselves we're in INCUBATION MODE and other processes in incubation mode work in google docs and very quickly ✪
<brent> I think 7 days is fine, especially in view of the desired iterative process.
... so we shouldn't let the GH format put us into a very deliberative process autopilot
Manu Sporny: I sympathize with both sides of this, we can't be too cautious but there are reasons to be cautious even though we're at such an early stage ✪
<mahmoud> happy 2 or 3
... so we can go ahead with Brent's version, then, if Mahmoud is happy
PROPOSAL: Any non-editorial PR can be merged as soon as 2 code owners approve the PR, if it has been open for a minimum of 7 days and change requests have been addressed.
RESOLUTION: Any non-editorial PR can be merged as soon as 2 code owners approve the PR, if it has been open for a minimum of 7 days and change requests have been addressed.
RESOLUTION: Rename the VC HTTP API to become the VC API.
Joe Andrieu: Just want to remark a famous remark of Tim Berners-Lee that he would never have named it HTTP if he'd known people would be saying URLs out loud every day ✪
<orie> its cool, some browser vendors hide it anyway...
<manu> Just to clarify, the full name of the renamed specification should be "The Verifiable Credential API"
Manu Sporny: Thanks to Justin for writing this up, lots of discussion. some of this content has been moved to other PRs ✪
Manu Sporny: How should we move forward with this, workflow and order of operations a little confusing ✪
Justin Richer: I marked this as a draft so as NOT to be merged. I put this in as a straw man/examples of the language the group *could* write ✪
... i think open or closed, this PR would be a good thing to cut and paste. I wanted it in the repo because I felt words kept getting put in my mouth
Mike Prorock: +1 Some very good language in here - note I think a lot has already been pulled out into other PRs ✪
... I think this group has been happy to do things like work with scope strings, and I think the comments in this thread are good questions about designing APIs with actions in mind
<orie> I provided feedback on the PR, but it has not been addressed.
Manu Sporny: I would recommend we leave it open as a draft PR so that we keep referring to it ✪
<mprorock> @orie - this is a draft PR - have some of the other PRs covered your comments?
... I think the AuthZ PRs that have been broken out of it already, and leaving it open keeps our options open if we add sections later that could also borrow from this
<orie> possibly... Im not against the idea behind his PR...
<orie> But it needs to graduate into a mergeable state.
Adrian Gropper: I'm glad to keep this open, and propose we not return to it until AuthZ sections have been substanciated a bit more ✪
Manu Sporny: I think you can only mark draft on a PR from a fork ✪
<mprorock> we need to trust the editors to read the comments for objections, changes requestd, etc
Justin Richer: I'm not a fan of "do not merge" because it can be used passive-aggressively ✪
<brent> on github repos where I have proper access I can convert any PR to draft.
<tallted> draft theoretically means that its author doesn't think it's ready for others to review, it exits draft for others to review, and *then* the merge question comes up.
Orie Steele: These descriptive labels are kind of orthogonal to the behavior we're expecting in the code owners ✪
... i think we need to remember the editors have power and responsibility
<orie> its been open for 10 days, no change requests
<orie> it should be merged immediatly
<orie> please merge it @manu.
<orie> they had 10 days to review it....
<orie> we just agreed to apply that policy.
Mahmoud Alkhraishi: +1 To Orie's point, assuming adrian's new CR's regarding the new name are accepted ✪
Manu Sporny: Here is a good test case where I'm worried about the new policy being applied literally ✪
<orie> just request changes if you want to block the PR... its trivial to do.
<orie> thanks Justin!
Justin Richer: Here is an editorial hackjob that takes the letter of my comment and not the spirit. I do not like this PR ✪
<tallted> Multiple open change requests ... and says it's a partial substitute for #226, which also remains open, so what's the actual choice to be made?
Mike Prorock: Note: Joe has good editorial changes requested ✪
Manu Sporny: That sounds like no objection to merge to me ✪
Adrian Gropper: I think this reflects a particular API AuthZ strategy and I'd rather this PR stay open ✪
<orie> there are no change requests, blocking the PR....
Ted Thibodeau: This opens with a confusing "Partial alternate to another open PR" disclaimer so it feels hedgey ✪
<orie> use the "request for change feature"
... I think the 226 versus alternatives thing is hard to parse
Mike Prorock: But if 226 is in draft and it's intended as a reference, this isn't an alternative, it's an offshoot of! ✪
<justin_richer> ZCAP and GNAP solve completely different problems, though ...
<orie> a normative statemen in a community draft...
Manu Sporny: Adrian does this make you happy or sad? ✪
<orie> I suggest approving or requesting changes Adrian and Justin.
<orie> I don't care about your feelings, but would love to see a PR review on this ;)
<orie> ( I do care about your feelings )
Adrian Gropper: As I've said before, I am interested in consensus on ideological questions, not low-level spec language. ✪
<orie> :)
Manu Sporny: I don't know how to help, we are working on spec language here. I keep trying to channel your comments as best I can in drafting these PRs ✪