This is the mail archive of the guile@cygnus.com mailing list for the guile project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
This is a hastily jotted format for the email submission format. Ideas, advice, and opinions appreciated (let's try to keep it at least pg-13, though ;') Each contents of each field must be enclosed in parenthesis... easy to parse, easy to make sure that exactly what you think is being submitted is being submitted. The only annoyance this brings is the necessity to escape '()' in the text (do the \( \) thing). A quick run down of commands. %start : appears at the beginning of each mail; possibly superfluous, but makes it easier to get right to the important stuff. %name (name of project): Must be unique. %password (password): this is an optional password for the entry (the alternative is gnupg signed messages, though this is likely to be implemented first). If given on the first email it sets the password (rather than randomly generating one); in subsequent mails, it's used to verify the modification. The rest of the commands will totally modify the given field of the record. %location (url): this should be a pointer to the homepage of the project, or the distribution if no page is available. %catagory (cat): this will be one of a set of pre-defined catagories. Basically, things like Application/Game or Library (module?) %description (desc): this should be a brief description (no more than a paragraph) of the project. %author (name): the main author of the project (should this be authors?) %contact (addr): an email contact for the maintainer (should this be folded into author(s)?) %status (status): the status of the project (maybe this should be called news? I'd expect that you'd want to update this whenever something interesting happens) %help_wanted bool: indicates whether additional programmers are wanted/needed. %testers_wanted bool: indicates whether the project wants people to test (this may be a bit superfluous). Some possible, desirable features: 1) Modification history of the various fields (how much will this cost, though... and how long should each bit of history be kept? I have no idea about the capacity of the host here). 2) probably other stuff. -- Greg