Re: [abcusers] developing the standard ......

[Bryancreer]

Anselm Lingnau said -

>Nothing should go in the
>standard unless it has been proved that it is actually implementable
>with reasonable effort. This may mean that sooner or later one might hit
>a dead end with some feature or other, but it will be much harder to get
>the standard fixed if the feature in question is already part of it,
>than to get the feature fixed *before* it goes into the standard. Of
>course if implementors insist that once they have implemented something
>then it must absolutely stay the way it is, then this approach doesn't
>work. However I think there is merit in trying things on a strictly
>experimental basis without encouraging users to base their multimegabyte
>ABC archives on those particular features that are being tested.

There is no "sooner or later" or about it.  This is what is already happening.  A notable example being the V: command.  There is a sort of Catch 22 which says "Well I have to try it out to see if it works"  followed by "I've put all that work into it and my users like it so I'm not taking it out now."

I don't think we can stop developers innovating but can we get them to at least keep everybody else informed and modify what they are doing if there is a clash?

Phil Taylor recently said -

>Before you start work, download BarFly, MUSE, Melody Assistant
>and all the other programs which you don't normally use.  Read
>the documentation and use the programs until you know what they
>are capable of.  

The wrong way round I feel.  Surely it is the responsibility of developers to keep the rest of the community informed of their innovations; not just just in their own documentation but in some central easily accessible place.

Bryan Creer