Re: Use Cases: proposed implementation of use case process

The PR process does have its benefits, but it makes tracking the status of a 
use case more involved.

peter


On 3/3/23 04:13, Timothée Haudebourg wrote:
> 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 <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 <mailto:pfpschneider@gmail.com>> wrote:
> 
>     See
>     https://lists.w3.org/Archives/Public/public-rdf-star-wg/2023Feb/0061.html
>     <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
>     <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 <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
>

Received on Friday, 3 March 2023 15:11:50 UTC