On Monday 08 Aug 2005 19:44, Stephen Torri wrote: > Honestly at this point I look forward to hearing what Chris and > others think about this.
Are you familiar with the book "Parkinson's Law"? http://www.amazon.co.uk/exec/obidos/ASIN/0141186852 This excellent collection of essays published in 1957 (my copy from 1961 was at least the fifteenth printing, at three-and-sixpence) contains all sorts of useful knowledge from the field of business -- I'm particularly fond of the discussion of how to lay out an application form so as to make it as hard as possible to complete. One of the more famous things in this book is the power-plant / bikeshed debate. "To the actual millionaire a million pounds is something real and comprehensible. To the applied mathematician and the lecturer in economics... a million pounds is at least as real as a thousand, they having never possessed either sum. But the world is full of people who fall between these two categories, knowing nothing of millions but well accustomed to thinking in thousands, and it is of these that finance committees are mostly comprised. The result is a phenomenon that has been often observed but never yet investigated. It might be termed the Law of Triviality. Briefly stated, it means that the time spent on any item of the agenda will be in inverse proportion to the sum involved." It's a simple enough thing -- if you aren't in a position to discuss something with any authority, or if you don't want to (or feel you haven't the time to) get involved in the debate, then you'll avoid the difficult bits of the conversation. But if you nonetheless feel you should have something to say, you'll end up arguing for hours about the pointless stuff instead. Guillaume is (as I am) trying to be helpful, but we're both latching onto the things that are easy to dispute, because we haven't managed to make the time to understand the rest. (There is also a more creditable motive, which is to object to apparent overengineering or redesigns or replacement of existing systems that are already serving us well.) > Perhaps my emails were not worded correctly to get people to respond > with opinions. Perhaps I did not learn the Rosegarden way of adding a > new feature early in the beginning of my endeavors. Rosegarden is much like any other project in this respect -- contributions get weeded out on the basis of the persistence and pigheadedness of their developers more than any technical merit. That's unfortunate, I know. > - What do the main developers want me to do? (A consensus of opinion > only) To this particular question about file formats? I say use XML, or use your own format if you like it, and make it possible to load, save and edit files in the GUI. That's the important bit. Other file formats are easily enough supported later, if there's any need. The only reason to do otherwise would be if there was an existing format used by lots of existing files that we wanted compatibility with. > - Who are the users of the guitar tab editor? Guitar players? > - Who are the users creating the guitar chord files? Anyone but me! My expectation is that it's the same guitarists. We only have one example of a Rosegarden-related file format that is widely used in a similar way, and that's the MIDI device (.rgd) files. These are gzipped XML and are essentially impossible for nontechnical users to create or edit. Nonetheless the format has been fairly successful, and that's because it can be created directly from the GUI (however buggy that part of the code may be). That's the interesting bit. Meanwhile, we also have a file format that can be used in the notation editor to define custom notation styles. This is a more niche purpose, sure, but the fact that only one person has ever ended up discussing them on this list suggests that the absence from the GUI of a way to create them easily makes a significant different to their approachability. (These are XML files too, by the way.) In general, the most important thing to do is get something visible working. In this respect I think you have been approaching things in the right way -- discuss upfront, but go ahead and implement the damn thing anyway. Once a feature is present and obviously of interest, the best ways to tune it can be evolved afterwards. Even a direction like "rewrite the parser to avoid using library X" is a lot more palatable if it's in the context of something that is mutually understood to be a success already. Fait accompli is still the most powerful force in a project like this, and it probably always will be. Chris ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
