Fonty Python Guidelines -- Feb 2007 Preamble ---------------------------------- Anyone contributing code should please take this as an attempt to ensure the quality and the spirit of the app. Those who join are agreeing to stick to the guidlines and to strive to meet them. Obviously if someone wants to take the code in a particular direction and does not want to adhere to the guidelines then they are welcome to do so and (they must) give their creation a new name. In fact, if additions to FP *do not* adhere to these guidelines then I will not fight with anyone or raise blood-pressure, I will simply consider that work a fork. As the initiator and primary developer I want the right to say "thanks but no thanks" if I see code going off the guidelines. That said, a plugin system is planned so that maverick functionality may be added and removed from the primary application. If anyone want to take that on, or help me plan it... Naturally, all Python puns are welcome and arguments cost only a small fee. The Guidelines ---------------------------------- FP has two PRIMARY purposes: 1) To view arbitrary fonts anywhere on the system. 2) To manage installation and removal of those fonts en-masse. Any additions to the code must either: A) Take both into carefull account. B) Be so different that they form new functionality which does NOT clash with the two primary purposes. Wherever possible, new code should revolve around the two purposes. If route B is taken, then I (and whoever else is interested) want open debate about whether that code should be in Fonty Python or become a plugin or become a fork. Quality ---------------------------------- I am very keen that code should be of a high quality both internally and externally. The idea is to make life really easy for the user. Internally: Code should be well remarked, in English (at a minimum). Variables should be descriptive and can be in any language as long as a short key is written in the comments giving an English explanation. Basically, make it easy for other eyes. Externally: I consider the user-experience paramount. FP should be slick and professional. a)Errors: Any code written should trap errors to the greatest extent possible and the app should report them (and exit gracefully.) Error trapping should be by design, be intentionally placed and thought about, not left until the end of the job as an add-on. b)Runtime: When FP is first run by a user it should make sure that all required Python modules are available. If not, the app should stop and leave the user with a clear description of what they must do to get it working. This should include instructions and at least a web address for the missing module. I also want an apt-get solution listed for Debian and *buntu distros. Certainly yum (Fedora) and others would be welcome too. When an app is run it should ensure that any external files or databases it needs are in place. Make no assumptions on behalf of your code; write that boring code that goes and checks. If something is amiss, inform the user in such a way that they can fix it. c)Interface appearance: Don't specify fonts or colours, let GTK do it. Icons and graphics should be carefully designed. I am a designer, so I don't mind if you leave that stuff up to me. I just don't want bad icons and horrible images anywhere. d)Help: The help should be written in HTML in English, at a minimum. Documentation is harder to do and the current standard (as of version 0.2.0) is not up to par. Documentation extends to the cli. When a user does a --help your options should be described. When the user does a --examples, your options should be represented there too. If any contributed code does not live-up to the quality guidelines a & b, then it cannot be included in FP. If it is suffering in c & d then it must be improved but can surely join the FP set of functionality. Command line use. ---------------------------------- FP was first conceived as a command-line application. All the main functions can be reached from the cli and I would like this to continue wherever possible. * As far as possible and to the maximum extent, new additions should supply command-line arguments. Contributions ---------------------------------- Any code contributed will acknowledge their author(s) by copyright notices in all relevant places. The licence is GPL v2. All modules used should include copyright and licence information. In closing ---------------------------------- I hope this is not too Draconian, I don't want to scare anyone away but I do want to keep a minimum level of quality. I am not an expert programmer and I certainly do not claim much more than a basic level of know-how or experience in things Gnu/Linux -- so please let me know how things can be done better and so forth. Best regard, and thanks for reading. Donn Ingle. Hermanus. South Africa.