Andrew Waterman called Thursday and we discussed many issues including challenges with Issues in Github.

We determined that both were unaware of some relevant aspects [neither of us intentionally blind];  and neither were exaggerating the our concerns [neither of us Chicken Littles].

Andrew volunteered me to look into Github:

Ffunctionality and features that might diminish some of the contention/problems related to "workflow" and "issue expression".

I consider myself duly deputized to:

  Recommend modifications to a de facto proposal by Krste on how to use Github, and

  To make any further suggestions that I consider valuable.

But before I get into that specific concern, there are related concerns

a) timeliness and completion of TG/SIG/other minutes

b) github issues vs group/list discussions

c) Philosophies and World Views.

It is the latter that I want to expound to help us understand the origin of some of the conflicts and to plot directions for resolution/enhancement in ISA development.

On the call, I admitted to being Process and Enablement oriented,  Andrew to being Task and Results oriented.

Those familiar with Holism vs Reductionism, know/understand that

1) both views are necessary to achieve significant results

2) at any point [level] in analysis there is value in considering

   i) the holistic nature of the concern/situation/object; its behaviour as a whole and response in the context of its environment [a sloppy definition, I know] and

   ii) the examination of its components; what it is made of, and why the what is needed [if needed] for what it does and doesn't do. [an even worse definition].

3) [most] persons have a bias towards one or other mode of analysis, but no one [who analyzes] is wholly one or the other.

These points are applicable to Process|Enablement  vs Task|Results.

1) both views are necessary to achieve significant results

2) at any point [level] in accomplishment there is value in considering

i) the Process|Enablement context; what enables the activity/accomplishment to occur.
How can it be enhanced/leveraged to assist in providing the desired outcome.
Put into place [Enable] the resources to accomplish the goal and let the process deliver the results. 

ii) identify the Task/activity that will [hopefully] yield the result and work that activity to completion
Verify the results are as hope for and check the task off the list
[ or check the task off the list and move to the next Task of verifying the result].

3) [most] persons have a bias towards one or other mode of operation.

So, back to Github and Issue Resolution.

A. These different Word Views may conflict at any given point [level] of endeavor.

It occurred in this instance in the conflict of when an issue should be closed.

For the Task|Result oriented, Issue Resolution is closing the issue.
     Task done, move on to next.

For the Process|Enablement, Issue Resolution is completing all the concerns expressed by ensuring a process is in place to address them.

     Closing prematurely aborts that process.

B. Github does not provide  robust Worrkflow Lifecycle in its base product for Issues.

For pull requests there is a support structure with: validations,  review requests/responses, and "sign-off" provisions.

Issue Life-cycle support is bninary/open close status [no UnderInvestigation,RequestingConsutation,TentativeResolution, Awaiting SignOff].

It does provide links to/from other issues, and more significantly has a CloseRelatedIssue Button when a pull is being applied to the repository.

Andrew mentioned the strong temptation to use this button when "finalizing" a pull request.

External email scripting could provide some functionality that would enhance the workflow,

  but the use agreement appears to discourage if not explicitly forbid such "non-standard" interfaces.

Github may have a pay-for-feature process [I remember such before its recent acquisition], however,

  I believe we can make do with moderate behavioural changes and still be effective in serving all of the RISCV community.

C. Oh. Contrary to Andrew's interference from https://github.com/riscv/riscv-isa-manual/pull/657#issuecomment-858481023 ,

          I do not believe unilateral control is desirable nor essential to Issue management "workflow".

I will have specific proposals soon.