<div dir="ltr"><div class="gmail_default"><div class="gmail_default"><font face="courier new, monospace">While Tim Barnes has posted this to the RT-Rules subgroup, I think this merits wider dissemination, as I suspect many who haven't been interested in the detailed discussions may still be interested in this. The Methods Committee has now posted on the CCCBR web site a precis of some changes it expects to propose at this year's Central Council meeting, as well as its plans for the following year. It is at</font></div><div class="gmail_default"><font face="courier new, monospace"><br></font></div><div class="gmail_default"><font face="courier new, monospace"><a href="https://cccbr.org.uk/services/methods/2017-consultation/">https://cccbr.org.uk/services/methods/2017-consultation/</a></font></div><div class="gmail_default"><font face="courier new, monospace"><br></font></div><div class="gmail_default"><font face="courier new, monospace">though it may be better to go to</font></div><div class="gmail_default"><font face="courier new, monospace"><br></font></div><div class="gmail_default"><font face="courier new, monospace"><a href="https://cccbr.org.uk/services/methods/">https://cccbr.org.uk/services/methods/</a></font></div><div class="gmail_default"><font face="courier new, monospace"><br></font></div><div class="gmail_default"><font face="courier new, monospace">as that provides a little more context.</font></div><div class="gmail_default"><font face="courier new, monospace"><br></font></div><div class="gmail_default"><font face="courier new, monospace">I urge everyone who's interested to read and comment on it.</font></div><div class="gmail_default"><font face="courier new, monospace"><br></font></div><div class="gmail_default"><font face="courier new, monospace">For whatever it's worth, appended below is the message I sent to the committee expressing my own views. In summary they are that (a) the few things proposed to be proposed are probably fine and worthy of support, though it is difficult to say for certainty as they have not actually presented concrete proposals; and (b) that they, and especially the plans for next year, don't go nearly far enough.</font></div><div class="gmail_default"><font face="courier new, monospace"><br></font></div><div class="gmail_default"><font face="courier new, monospace"><br></font></div><div class="gmail_default"><font face="courier new, monospace">---------- Forwarded message ----------</font></div><div class="gmail_default"><font face="courier new, monospace">From: Don Morrison <<a href="mailto:dfm@ringing.org">dfm@ringing.org</a>></font></div><div class="gmail_default"><font face="courier new, monospace">Date: Thu, Mar 16, 2017 at 7:25 PM</font></div><div class="gmail_default"><font face="courier new, monospace">Subject: Response to the 2017 consultation</font></div><div class="gmail_default"><font face="courier new, monospace">To: CCCBR Methods Committee <<a href="mailto:methods@cccbr.org.uk">methods@cccbr.org.uk</a>></font></div><div class="gmail_default"><font face="courier new, monospace"><br></font></div><div class="gmail_default"><font face="courier new, monospace"><br></font></div><div class="gmail_default"><font face="courier new, monospace">I read with interest the consultation document that has recently appeared on the Methods Committee's page of the Council's web site. Here are my thoughts.</font></div><div class="gmail_default"><font face="courier new, monospace"><br></font></div><div class="gmail_default"><font face="courier new, monospace">Regarding the proposals for 2017:</font></div><div class="gmail_default"><font face="courier new, monospace"><br></font></div><div class="gmail_default"><font face="courier new, monospace">Since you have not included the actual text of your proposals it is, of course, impossible for me to comment on them meaningfully. I will do so once you have distributed them. That said, I wholeheartedly support the goals of the four proposed proposals. All are long overdue. But the devil is in the details, and without seeing the actual wording it is not at all clear how much of an improvement the changes will actually be.</font></div><div class="gmail_default"><font face="courier new, monospace"><br></font></div><div class="gmail_default"><font face="courier new, monospace">For example, will the changes be made by reducing the size of the existing decisions, as they should? Will Change 3D be implemented by removing restrictions and the language in which they are couched? Or will it instead, sadly, be implemented by adding yet more special cases and additional sentences? Or you allude to "a definition of what a simulator is, and specify the minimum amount of human interaction"--this seems a fruitful opportunity for unintended consequences, for which it would be most helpful to see what, exactly, it is that is being proposed.</font></div><div class="gmail_default"><font face="courier new, monospace"><br></font></div><div class="gmail_default"><font face="courier new, monospace">While I applaud the goals of these four proposed proposals, I am deeply disappointed both in their tiny scope, and in their sketchy presentation. The existing decisions are a large, convoluted mess of rules from the past hundred years, that have been amended will-nilly, and are long past the point they need to be completely replaced. Yet there is no evidence of any recognition of that fact, or effort towards accomplishing the long overdue correction. Last year, at the very last minute, a small collection of pressing amendments were produced. While all were improvements, they merely delayed the long needed overhaul another year. Along with them came a promise to do better this year. Yet this year, it is the same thing yet again. Far too little is being proposed, and, of course, that is as it must be because it is all being proposed far too late. Had proposals been made in this past winter, as promised, far more could have been accomplished.</font></div><div class="gmail_default"><font face="courier new, monospace"><br></font></div><div class="gmail_default"><font face="courier new, monospace">Regarding 2018 and beyond:</font></div><div class="gmail_default"><font face="courier new, monospace"><br></font></div><div class="gmail_default"><font face="courier new, monospace">Regarding use of the identity change: I VERY STRONGLY suggest not referring to this as the "null change", but rather as the "identity change". For reasons I do not understand the words "null change" provoke an intemperate, visceral reaction having nothing to do with the topic of discussion: "null change" seems to be interpreted by many as something that it is not. The use of "identity change" also has the advantage of being closer to typical use in other spheres of endeavor that deal with permutations.</font></div><div class="gmail_default"><font face="courier new, monospace"><br></font></div><div class="gmail_default"><font face="courier new, monospace">In general, I am sorely disappointed with the proposal for next year's work, on two grounds:</font></div><div class="gmail_default"><font face="courier new, monospace"><br></font></div><div class="gmail_default"><font face="courier new, monospace">- It does not go far enough.</font></div><div class="gmail_default"><font face="courier new, monospace"><br></font></div><div class="gmail_default"><font face="courier new, monospace">- It appears to yet again be just tweaking, amending, and adding to the existing overly large and complex mass of decisions, rather than creating a new framework, as needs to be done.</font></div><div class="gmail_default"><font face="courier new, monospace"><br></font></div><div class="gmail_default"><font face="courier new, monospace">Most of the items you propose addressing I wholeheartedly support. However, they should not be addressed piecemeal. They should instead be incorporated from the ground up in a new, tighter, more coherent, and less prescriptive framework. Addressing them piecemeal just adds to the problems that need resolution.</font></div><div class="gmail_default"><font face="courier new, monospace"><br></font></div><div class="gmail_default"><font face="courier new, monospace">Regarding reporting, be careful not to tie the wording to exactly the technology that exists today. I should be possibly for the technology to evolve without requiring the Council to change its decision every time that technology moves on.</font></div><div class="gmail_default"><font face="courier new, monospace"><br></font></div><div class="gmail_default"><font face="courier new, monospace">Regarding "compliance", I think the whole notion of "requirements for peals" is completely misguided. The goal of the Council should be to record what ringers choose to do, not to make requirements they may or may not adhere to. I am vehemently opposed to your Option 2: anything that establishes a two-tier system invariably results in some peals traveling first class and others steerage. Of the options you enumerate, certainly Option 3 is the best.</font></div><div class="gmail_default"><font face="courier new, monospace"><br></font></div><div class="gmail_default"><font face="courier new, monospace">It is ludicrous to completely defer addressing jump changes. Methods containing jump changes are rung today. To pretend that those ringing such things are not performing change ringing is absurd. If folks want to include extents of such methods in peals, there should be no impediment. Yes, of course, the detailed categorization that has been done with non-jump-change methods would be difficult to apply to methods with jump changes; don't even try. There is no need yet for a detailed taxonomy (indeed, I would argue there is too much taxonomy for non-jump-change methods already). Simply recognize that they are possible and ensure any proposed, overall framework doesn't disallow them. It needn't go to any great depth in dealing with them, but don't pretend they don't exist. The do.</font></div><div class="gmail_default"><font face="courier new, monospace"><br></font></div><div class="gmail_default"><font face="courier new, monospace">I am strongly in favor of allowing folks to start or end peals in interesting ways if they so choose, rather than discouraging them, as is the case today. This, too, should be accommodated from the word go (oops, sorry for the pun) in a new, comprehensive framework.</font></div><div class="gmail_default"><font face="courier new, monospace"><br></font></div><div class="gmail_default"><font face="courier new, monospace">There is no reason to disallow the identity change (NOT "null change", please!). I have rung many quarters using it. It is perfectly natural and useful. For example, a 12345 single in Plain Bob Doubles is straightforward and natural to ring; in my experience most ringers just do it naturally as the obvious cognate to singles from Plain Bob Minor. It is by far the easiest way I know to ring lengths such as 50 of Plain Bob Doubles. And a simple, natural 240 is to make six calls at Home, --s--s: it contains every row once at hand and once at back, and has a perfectly even distribution of the six possible coursing orders. Allowing use of the identity change should not be deferred, but incorporated in a new framework, as soon as it is possible to construct one.</font></div><div class="gmail_default"><font face="courier new, monospace"><br></font></div><div class="gmail_default"><font face="courier new, monospace">There is no reason to defer allowing peals on 2 or 3 bells. That are the natural starting point for what we have today. I have no interest in ringing such peals, but if others do it is ridiculous that we stand in their way.</font></div><div class="gmail_default"><font face="courier new, monospace"><br></font></div><div class="gmail_default"><font face="courier new, monospace">Relay ringing was a natural thing in the past, and has only over the last century and a bit been denigrated. If that's what folks want to do, we should not stand in their way. Again, there is no reason to defer this change, and it should be incorporated in a new framework, essentially now.</font></div><div class="gmail_default"><font face="courier new, monospace"><br></font></div><div class="gmail_default"><font face="courier new, monospace">There should be NO formalized requirements for quarter peals. The whole problem being dealt with is that there are too many requirements for peals. You do not solve the problem of too many requirements by adding more and making them applicable to more things. The quarter peal community is getting on just fine without the Council's "help".</font></div><div class="gmail_default"><font face="courier new, monospace"><br></font></div><div class="gmail_default"><font face="courier new, monospace">Regarding method extension, classification and alternative names: there is far, far too much here already, of too prescriptive a nature. A new, shorter, tighter, less prescriptive framework is a perfect opportunity to simplify this whole area, and get out of the way of the ringers the Council purports to support.</font></div><div class="gmail_default"><font face="courier new, monospace"><br></font></div><div class="gmail_default"><font face="courier new, monospace">Do not delay further. Get on with the job that needs doing, and create a new, shorter, tighter framework now. There is no reason work on drafting such a thing can't go on in parallel with whatever preparations must be done for this year's Council meeting. Of course such a job is too big to get done in time for the meeting, but there is no reason work on it cannot proceed in parallel with the less ambitious work.</font></div><div class="gmail_default"><font face="courier new, monospace"><br></font></div><div class="gmail_default"><font face="courier new, monospace"></font></div><div class="gmail_default"><font face="courier new, monospace"><br></font></div><div class="gmail_default"><font face="courier new, monospace">-- </font></div><div class="gmail_default"><font face="courier new, monospace">Don Morrison <<a href="mailto:dfm@ringing.org">dfm@ringing.org</a>></font></div><div class="gmail_default"><font face="courier new, monospace">"She would be immortal as long as she lived."</font></div><div class="gmail_default"><font face="courier new, monospace"> -- Terry Pratchett, _Thief of Time_</font></div><div><br></div></div>
</div>