- From: Peter F. Patel-Schneider <pfpschneider@gmail.com>
- Date: Thu, 2 Mar 2023 16:05:38 -0500
- To: RDF-star WG <public-rdf-star-wg@w3.org>
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
Received on Thursday, 2 March 2023 21:05:51 UTC