[NeXus-committee] NIAC: seven online votes!

Thu Feb 13 00:17:48 GMT 2025

Hi all, here are the voting results:

   - Passed, 15 yes.  Allow for open enumerations #1521
   <https://github.com/nexusformat/definitions/pull/1521#issuecomment-2617047160>
   - Failed, 10 yes (14 needed for quorum).  Fairmat 2024: additions and
   clarifications in NXbeam #1408
   <https://github.com/nexusformat/definitions/pull/1408#issuecomment-2617049939>
   - Passed, 12 yes, 1 no, 2 abstain.  NXcomponent as a parent base class
   #1525
   <https://github.com/nexusformat/definitions/pull/1525#issuecomment-2617052302>
   - Passed, 15 yes.  Implement-NXobject-inheritance #1507
   <https://github.com/nexusformat/definitions/pull/1507#issuecomment-2617055267>
   - Failed, 12 yes, 1 abstain (14 needed for quorum).  Move NXlens_em to
   base classes #1519
   <https://github.com/nexusformat/definitions/pull/1519#issuecomment-2617058029>
   - Passed, 14 yes. Fairmat 2024: several new base classes in NXsample and
   NXsample_component #1413
   <https://github.com/nexusformat/definitions/pull/1413#issuecomment-2617062395>
   - Failed, 11 yes, 1 abstain (14 needed for quorum). [resubmission] move
   NXpid_controller to base_classes #1528
   <https://github.com/nexusformat/definitions/pull/1528#issuecomment-2617066301>

Regarding the above conversation, thanks Paul for the interesting ideas and
discussion!  At the end of the day, I felt I could only follow the rules
using a fairly strict interpretation.  Therefore I resolved all comments on
the PRs that passed their votes and approved them for merging.  My
philosophy is that once a vote starts, it's really too late for a more
serious review.  We were able to fix some things in the voting process, but
the time for review is *before* the vote starts.  Therefore, those that
passed should be merged as is, with our grateful thanks to the FairMAT team
and all that participated (especially Paul!)!  However, for those that
passed that still had comments on them, could the authors please rescue any
ideas that need to persist into new issues?

We'll discuss the three that failed tomorrow at the Telco.  I believe they
had enough comments that were blockers such that they didn't pass.

Thanks,
-Aaron

On Thu, Feb 6, 2025 at 6:07 AM Paul Millar via NeXus-committee <
nexus-committee at shadow.nd.rl.ac.uk> wrote:

> 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.
>
> _______________________________________________
> NeXus-committee mailing list
> NeXus-committee at nexusformat.org
> https://lists.nexusformat.org/mailman/listinfo/nexus-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.nexusformat.org/pipermail/nexus-committee/attachments/20250212/767352f2/attachment.htm>