[r-t] Decisions

[Graham John]

Robin wrote:

> How many on this list apart from Richard, pabs and me (on a good
> day) even begin to get close to any real understanding of this topic?
> No one seems to join in!

It doesn't mean that we aren't listening though!

It is worth just stepping back from the examples to consider why we need the
extension rules anyway. Essentially the benefit to ringers of using the same
name for methods at different stages is that if they are sufficiently
closely related, then they should be easier to learn, perhaps involving no
additional learning at all - Kent TB, for example.

Taking this view, it is easy to see where Robin is coming from, in that the
way people learn methods is important, since you want the rules and tips
people use to learn a method to work on different stages. However, the
problem is that people learn methods in different ways (e.g. the work vs the
grid), and indeed learning techniques used by the same ringer may vary from
method to method. 

While people are comfortable with the extensions of Kent TB and Cambridge S,
someone who knows York S Minor as Cambridge above and London below is not
going to find the extension to Major much help at all. It is also worth
noting that the current decisions also allow the same name to be used for
completely unrelated methods method of a different class, such as Oxford TB
and Oxford S Major. This is of no help to learning at all.

We need the CC to provide a framework for extension which:

- produces relationships which ringers recognise and can use to aid learning

- is agreed by the majority of interested parties
- is consistent and understandable
- is easily applied so anyone can work out a correct extension

We are currently struggling on all counts!

It has become too complex, and I don't think that we can properly understand
the ramifications of any proposed amendment without using software to test
the decisions and any amendments thoroughly. So I think we need to:-

1. Encode the current extension rules into software
2. Encode suggested amendments to the rules which have been proposed
3. Make the software available to interested parties   
4. Process the existing method libraries to identify all extensions which
are inconsistent
5. Produce unrung examples of extensions for different classes of method for
review and agreement by interested parties
6. Compare the effects if proposed amendments are applied
7. Formally propose the agreed amendments for adoption by the CC
8. Make the definitive extension software available on the web for anyone to
generate or test the validity of their new methods* or extensions
9. Publish the list of historic anomalies

Richard Smith has already demonstrated the feasibility of much of this.
Taking his work forward and completing these steps would takes us a long way
forward, since anyone would be able to produce their own extensions and
check their own method names without recourse to the methods committee on
each occasion.

Graham   

* A by-product of such software is that it could derive the definitive class
for a new method and check that it isn't accidentally an extension or
contraction of an existing method.