[r-t] Opinions sought

[Tim Barnes]

On Mon, Jan 21, 2019 at 10:52 PM Don Morrison <dfm at ringing.org> wrote:

> Why? Does not the latter correspond more closely to current practice,
> with this row-based idea being brand new?
>

Yes, but it doesn't work in the new descriptive world where non-round or
non-true blocks ought to be covered, however rarely they might be rung.  We
therefore needed to update the definition of spliced.  The CRAG mandate
asked for simplicity, permissiveness and historical continuity, but in some
cases (including this one) these are in opposition to each other and we
needed to search for what we thought were the best trade-offs.

Permissiveness was added by not requiring all extents / MEBs to be spliced
for the performance to be spliced.  "It's spliced unless all changes of
method occur at rounds" gave simplicity.  The trade-off was historical
continuity -- if a multi-method MEB's changes of method all occur at
internal rounds, the MEB will no longer be spliced.  This seems a
reasonable trade-off given the unlikelihood of all changes of method
occurring at internal rounds, but clearly different people will assign
different weights to the three CRAG criteria.

Over 40 people took part in the framework consultations and Don was the
only person to question the definition of spliced.  Of course we don't know
how carefully people thought about all the framework definitions, and
obviously many people didn't take part at all.  There will probably be more
scrutiny of the framework as it's implemented, and if it emerges that
something clearly goes against general ringing opinion, this will be taken
up in version 2.


On Tue, Jan 22, 2019 at 4:15 AM <iain at 13to8.co.uk> wrote:

> Is the problem here that you are trying to come up with a simple
> definition for spliced when it actually means two different things.
>
> Pure spliced I believe is clear to everyone, but when a touch is
> laminated, as in the examples given, there is a lack of agreement as to
> whether it is spliced, or mixed (or what term you wish to use).
>
> Having two definitions, and acknowledging that people may use the word
> spliced differently might solve the problem.
>

I don't think that's the problem -- the challenge is with the definition of
spliced itself in a permissive / descriptive world.  The framework's
performance reporting section includes 'mixed' as an optional term that can
be used for any multi-method performance that isn't 'spliced'.  'Mixed'
isn't in the Decisions, but we included it as an optional term because it's
widely used on BellBoard:
https://bb.ringingworld.co.uk/search.php?title=mixed
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://bellringers.org/pipermail/ringing-theory/attachments/20190123/9236ff4f/attachment.html>