<div dir="ltr"><div dir="ltr"><div dir="ltr">On Mon, Jan 21, 2019 at 10:52 PM Don Morrison <<a href="mailto:dfm@ringing.org" target="_blank">dfm@ringing.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><span style="font-family:"courier new",monospace">Why? </span><span style="font-family:"courier new",monospace">Does not the latter correspond more closely to current practice, with this row-based idea being brand new?</span></div></div></div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div><br></div><div><div dir="ltr" class="gmail_attr">On Tue, Jan 22, 2019 at 4:15 AM <<a href="mailto:iain@13to8.co.uk">iain@13to8.co.uk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-GB"><div class="gmail-m_2590124058357565032WordSection1"><p class="MsoNormal"><span style="color:rgb(31,73,125);font-family:Calibri,sans-serif;font-size:11pt">Is the problem here that you are trying to come up with a simple definition for spliced when it actually means two different things.</span><br></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">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).<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Having two definitions, and acknowledging that people may use the word spliced differently might solve the problem.</span></p></div></div></blockquote><div><br></div><div>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: <a href="https://bb.ringingworld.co.uk/search.php?title=mixed">https://bb.ringingworld.co.uk/search.php?title=mixed</a></div></div><div><br></div></div></div></div>