# Solid Authorization Panel July 22nd, 2020 ## Attendees - Justin B - Dmitri Z - Henry S - Davi O - elf Pavlik - Sarven C ## Agenda - Publishing draft proposals - Use Case Review (https://github.com/solid/authorization-panel/pull/84) ## Minutes ### Mechanism for publishing draft Pavlik has looked at netlify as an option for this Example at https://github.com/elf-pavlik/authorization-panel/pull/1 - see checks and follow detail link in netlify check Action #1 - Check with netlify on free option for open source Action #2 - Look at an alternative approach using github actions for publishing draft proposals (from non-master). Ideally it would amend the pull request with a pointer. Action #3 - Aim to resolve this by next session SC: could we not use bikeshed and just plain HTML EP: -1 to plain HTML JB: strongly recommend bikeshed DZ: will still need some rendering infrastructure regardless (both plain html and bikeshed are equally unusable without some rending infrastructure) ## Use Case Review https://github.com/solid/authorization-panel/pull/84 JB: what do we need to merge it eP: i would propose to merge it as it is and follow up with focused issues and PRs addressing those issues SC: ensure we have agreement on what the implications of `merge` means. EP: emphasize that we can always raise issues inline in the text and tie to github issues for continued discussion. JB: in panel we try to get draft writen, we shouldn't merge PRs that don't represent direction/purpose of the panel. one can also submit PR which just adds inline issue raised on github. not until we submit it to specifications repo it represent full consensus of the panel. SC: Proposal to record panel member interest/votes on user stories/use cases. SC: Recommend having a separate doc that tracks acceptance / votes on individual use cases - https://www.w3.org/wiki/Socialwg/Social_API/User_stories JB: What does +1 / -1 imply in that context? SC: Good faith rough voting. Meant to indicate agreement / relevance / priority / acceptance by users and implementers. See https://github.com/solid/specification/issues/9 EP: SocialWG didn't use PR flows (which we have now with Github). People independently were throwing in use cases. If we have initial ones merged with PRs to add/adjust then we have a safer harness to work in and address. EP: Propose only tracking objections, and use inline github issues in the text to track those. EP: Believe it's most important to track implementation support. SC: Okay with that - as long as we track objections, implementation support. EP: proposing action item to sarven to setup opinion pool on use cases to vote HS: Will want to add some use cases. Not crazy about +1 / -1 absent being able to provide in-depth response and defense. These are just use cases that may not always be obvious to people doing more high-level review. Knowing how it implementing is extremely important. ACTION ITEM: Sarven will setup vote / opinion poll ACTION ITEM: Merge #84 and iterate with considerations.