Meeting minutes
Approval of meeting minutes
laurens: Lazy consensus for meeting minutes approval
… if there is no objection to the minutes, the goal is that minutes would be approved automatically
jacoscaz: I approve this idea
hadrian: I second that
laurens: do we need a formal proposal?
laurens: PROPOSAL if there are no objections to meeting minutes, they auto-approve after seven days
<laurens> +1
<hadrian> +1
<acoburn> +1
<jacoscaz> +1
<cpn> +1
<ryey> +1
<eBremer> +1
<TallTed> +1
<ericP> +1
RESOLUTION: if there are no objections to meeting minutes, they auto-approve after seven days
<csarven> ack+
Pending Action Items
laurens: Jacopo sent out email asking for input on alternative times
<laurens> acoburn: I've created a scribe list from the previously active members in the WG meetings
<laurens> acoburn: I've put names of all members in there, except the members from Korea who haven't attended yet
<laurens> acoburn: People uncomfortable with scribing or not attending the meetings regularly can remove themselves from the scribe list.
<laurens> acoburn: This is how we'll manage the scribe list for now.
<laurens> acoburn: The second item on my to-do list, once PR pr#5 has merged, I will contact people who have already submitted their issues to reformat to the new template
<gb> Issue 5 not found
<hadrian> w3c/
<gb> Pull Request 5 feat: add a use cases template for github issues (by laurensdeb)
Status of the use cases document
hadrian: use cases template is not merged yet
… realized there are some issues that could be discussed in this meeting
… one issue: do we have a preference for review-then-commit or commit-then-review
… another significant issue is that there is a difference between use cases and user stories
… user stories focus more on the value provided to users
… use cases focus on how users interact with system
… personally, I prefer both
… assume the template will change over the upcoming months, would like to introduce a version number for the format
… why would the template be in the github location and not elsewhere
… after the meeting today will merge the PR
<Zakim> ericP, you wanted to say that before review for first publication, i'm happy with the editor having the simplest workflow
laurens: commit-then-review works for me. Whatever works best for the editors
… the location of the template is located where it is because it allows us to use GH issues
… we may need to review GH branch protections
… preference for use cases, but they are equally relevant
… it would be good to keep them separate
ericP: good to have the editor commit directly to the repository
… in terms of user stories vs. use cases is the distinction in terms of technical detail?
hadrian: first, replying to laurens, if we keep both use cases and user stories we need to keep them distinct
… user stories are more general; use cases are more structured
… use cases represent interactions with the system and have a closer connection to a protocol
… user stories capture what a user expects from the system
… example user story: "as an actor, I would expect ... in order to achieve ..."
<Zakim> ericP, you wanted to say that a pattern i've appreciated in the past is when the UC&R has a short paragraph with a user story, then a more detailed example including interactions (which are later coded for requirements)
ericP: a pattern I've seen in the past is a paragraph with the high level user story
… then, a more detailed use case follows
csarven: ericP's suggestion makes sense to me
… group can decide if we need separate docs or not
… question on the actual proposal re review-then-commit vs. commit-then-review
… what does a commit entail? Does that mean the use case is accepted?
… the review-first path (i.e. creating issues) can allow participants to refine proposals before they are committed
… if the use case is clear enough, then it can be translated into the document
… it is unclear who has access to commit, we would need to clarify that
hadrian: in general, I agree. When the commits are only editorial commits, I could create a PR like others
… personal preference is that even editorial commits are submitted as PRs
… should be no commits that come out of the blue, with at least 24 hrs to review
csarven: does that mean that anyone could raise a PR? rather than open issues?
hadrian: anyone with a use case to contribute will submit a PR. Once some consistency is reached, the editor will merge
… for editorial commits, those also use PRs
csarven: in terms of process, there should be five to ten business days for review
hadrian: once we've reached consensus, there would be one more day for the editorial commit
csarven: how long should the review period be?
… in Solid there are expected review periods for specific types of changes
hadrian: I would err on the side of making progress faster
<csarven> Decision period for changes, e.g.: https://
jacoscaz: first, in terms of setting review time. I would suggest that we trust the chairs
… the process would be smoother is the chairs set expectations for the review time for different PRs
<Zakim> jacoscaz, you wanted to mention evolving use cases after discussing user stories and to suggest a lighter approach based on trusting chairs
jacoscaz: in terms of difference of use cases and user stories, can hadrian confirm
… it would be good to get feedback on user story before spending time translating that into use cases
laurens: we are trying to collect use cases and user stories
… will there be a subsequent step where they are groomed and prioritized?
… this first step is more of a triage step
… this first step is not necessarily a commitment to take on these use cases
… I would prefer to have a lighter weight process at this stage
… later we can look into transforming this into a WG note
… which would have a longer review period
… in summary: this stage should be quick and light-weight
hadrian: I don't think it will be purely sequential
… there will be parallel work, and that is the work of the editor
… in terms of commitment, that will be based on requirements
laurens: yes, we agree that requirements are where the commitments are
… agree that this will be an iterative process, but we will need a first draft before getting to the protocol drafting stage
<Zakim> ericP, you wanted to propose that before initial review for UC&R publication that we leave everything to the discression of the editor
ericP: we are currently in a stage where we need to write as much down on a white board as possible
… at this stage, we mostly need to know if there is redundancy
… once we are at the point of publishing a UCR we will review more formally
… until then, I would like to let the editor decide how the use cases are submitted
TallTed: as user stories are being submitted, these are plain-English descriptions (e.g. Jane needs to add contacts to an address book)
… these don't really need collaborative editing
… this can easily go into issues, where they can be closed (e.g. duplicate or out-of-scope)
… once they go into use cases, they will need more collaborative editing
… at that stage, an issue thread is not very effective
… once we are at a point of collaborative editing, PRs tend to be easier
… strongly recommend using PRs (rather than straight commits)
… providing time for review is important
… sometimes changing a comma to a semicolon can significantly change the meaning
… would suggest 3-5 business days
hadrian: I very much agree
laurens: to summarize: a process where individuals will propose user stories/use cases as pull requests with a 3-5 day review period
… we will then distill those use cases/user stories into requirements, which will form the commitments of the group
… does csarven feel remarks are addressed?
csarven: yes, I wanted something concrete
laurens: in terms of action items, hadrian will make some changes to the template and then merge
TallTed: it is important to note that standards development take longer than developing software
… in a short period of time, changes will be more significant
… others outside of this group will start implementing
… it will be harder to change things
laurens: agree that the standards development is going to require a more thorough process
… any other comments related to this topic?
… next WG meeting will be next Monday, same time