[NeXus-committee] NIAC: seven online votes!

[Paul Millar]

Hi Aaron,

Since nobody seemed to reply, I'll add my 2c's worth.

On 03/02/2025 18:58, Aaron Brewster via NeXus-committee wrote:
[...]
> There are three kinds of comments.  1) Those that are obvious and should 
> just be fixed.  Things like typos or easy fixes that wouldn't affect 
> anyone's vote by any rational measure.  2) Those that are substantial 
> enough that they should probably be addressed after the vote, but 
> shouldn't really affect people's votes.  3) Dealbreakers that cause a no 
> vote.

I like the idea of classifying feedback.  Trying to convey the intended 
reaction through natural language can be tricky, so having certain 
categories of feedback is good.

For some of my comments, the intention (initially) is to have a better 
understanding of what is being proposed.  This _might_ suggest the 
description could be improved (after all, the description should inform 
the reader of the semantics).  However, equally, my question could 
simply reflect my own ignorance on a particular topic.

In the following, I've tried to take your ideas and formulate them into 
different states or labels.

   EXPLORATION -- I'm asking a question without any implied problem.

   EASY_FIX  -- I think there is a problem but the solution is easy
	and obvious.  It should not affect how people have voted, so
	the PR may be directly updated by the proposer.

   DISCUSS_FIX -- I think there is a problem.  The solution is not
	easy and obvious, so some discussion may be needed.  The
	problem should not have affected how people have voted, so
	the PR may be updated once the solution has been agreed.

   BLOCKING -- I think there is a problem.  The solution is not easy
	or obvious, so some discussion is needed.  The problem is
	sufficiently serious that I am voting thumbs-down.
	Moreover, the discovery of this problem might affect how
	people would like to voted.

These three (EASY_FIX, DISCUSS_FIX, BLOCKING) imply that the PR is 
updated before the proposed changes are merged.  I'd suggest one further 
one:

   FIX_LATER -- I think there is a problem.  The problem does not
	affect how people voted nor the validity of the PR.  No
	changes are needed for the PR, but the problem should
	still be fixed.

These name (e.g., "EXPLORATION") are just place-holders, we could use 
them but I'd be fine if someone thought up better names.)

I could imagine the designation as somewhat fluid.  For example, a 
comment would start as EXPLORATION, a subsequent comment could then 
switch to DISCUSS_FIX; later still, a comment updates to EASY_FIX.

Ideally, any designation should be mutually agreed, but (I would say) 
this is a way for someone who can vote to engage outside of a ternary 
yes/no/abstain.

Does this make sense, or is it too complicated and/or confusing?

> My suggestion for Lukas:  for 1) just do the fix and for 3) keep the 
> comments unresolved for more discussion.  For 2) we can follow this 
> procedure:
> 
>   * Start a new PR that is based on the existing PR branch, addressing
>     those comments
>   * Resolve a comment at the bottom of the original PR noting the new PR
>   * Resolve the comments in the original PR the new PR will address
> 
> Any objections from the committee?

This would be a way to recover from DISCUSS_FIX comment.  The process 
sounds reasonable to me.

My only concern is that (I believe) GitHub will hide comments once they 
are resolved.  This might make it harder to navigate from the PR to the 
new PR (the one resolving the issue).

Cheers,
Paul.