Re: Use Cases: proposed implementation of use case process

Hi Peter,

A third alternative would be to use pull requests. We could have a
repository containing a collection of files, each file defining a use case.
Anyone can propose a new use case by creating a new pull request
introducing a new file to the repository. Because it is just a regular
GitHub PR, reviewers can use the built-in mechanism to request changes,
suggest changes that can be directly incorporated into the PR [1], or
reject the PR altogether. Accepting the PR would automatically add the use
case to the collection without additional work from the task force.

Just like with the issues mechanism, we can label to PRs. And just like
with the wiki mechanism, if use cases are written in Markdown, GitHub will
directly render them without showing the source text when a reader is
browsing the repository files.

-- 
Timothée

[1]:
https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/incorporating-feedback-in-your-pull-request#opening-an-issue-for-an-out-of-scope-suggestion

On Thu, Mar 2, 2023 at 10:05 PM Peter F. Patel-Schneider <
pfpschneider@gmail.com> wrote:

> See
> https://lists.w3.org/Archives/Public/public-rdf-star-wg/2023Feb/0061.html
> for the original proposed process
>
>
> There appear to be two ways to implement use cases in GitHub.
>
> One is to use a wiki, where submitters create a page for the use case that
> can
> be edited as the use case progresses.  This has the advantage that editing
> is
> open, that all changes are done to the wiki page, and that the use case is
> a
> single page.  It has the disadvantage that submitters would have to copy a
> template to start a use case.  See https://github.com/pfps/use-cases/wiki
> for
> an example of how the wiki process could work.
>
> The other is to use issues, where submitters create a new issue using a
> template.  This has the advantage that comments can be made without
> changing
> the use case itself and the related disavantage that it is harder to
> produce a
> clean version of the use case unless care is taken to update the first
> comment
> (and it may not be possible for all working group members to edit
> comments).
> This also has the advantage that labels can be associated with the issue
> to
> track its status.  See
> https://github.com/pfps/use-cases for an example of how the issue process
> could work.
>
> I think the issue option will work out better as long as the initial
> comment
> in an issue can be edited by members of the working group and the
> submitter of
> the issue.  The ability to assign labels that can be used in searches is
> quite
> powerful here and the template mechanism is useful.
>
> In either case, a task force of the working group would look at submitted
> use
> cases and collaborate with submitters to complete them.  The working group
> would then consider a submission and either approve or not approve or
> request
> more information (or just make no decision).  Only the initial edited
> comment
> would be considered an official part of the use case.  The output of the
> working group would be evaluated against approved use cases.
>
> I forsee two possiblities for completing initial use case submissions.
> The
> original submitter might be motivated to complete the use case, possibly
> with
> the help of a working group member.  Otherwise a working group member
> might
> take up a use case and complete it.  There is also the possibility that
> neither of these happen, in which case the use case will remain incomplete
> and
> if the working group does consider the use case it would likely not be
> accepted.
>
> TODO:  Determine whether some repository can be set up to allow submitters
> and
> working group members to edit comments in issues.
> TODO:  Determine which implementation option to choose.
>
> peter
>
>