On Thu, 13 Sep 2007 16:24:08 -0700 Thanasis Kinias <tkinias@kinias.org> wrote: > _This_ is a subject worth discussing. How can we, perhaps, improve the > template or the documentation on mentors.d.n so that we can improve the > `hit rate', as it were. The template is more or less right - what is missing is the emphasis on "filling in the gaps"; emphasis that the maintainer needs to add package-specific information to the template in nearly all cases. > I would suggest (and the number of RFSes which you find inadequate seems > to support this idea) that the instructions on the Web site do not go > far enough in explaining what is needed. A first-time user could very > well assume, I believe, that what is expected is to fill the blanks in > the RFS template and the rest is self-explanatory. It would be good for all users, especially first-timers, to be fully aware that no template can cover all packages and that the maintainer needs to do the work and provide full details in the RFS. In particular, the section from the FAQ: > " Your message to -mentors is like an ad for your package. It's likely > to be the only thing that prospective sponsors will judge your package > on. You can have all the extra URLs you like in there where sponsors > can get more information, but unless your initial message piques their > interest, they'll never look at them. > > So, tell us what exactly your package does, and why it should be in > Debian. If there is already a program that does a similar thing, say > why your one is better. Put a little "hot spice" in there to hold > people's interest. in other words, think like an advertising executive. > Just remember to wash the slime off afterward. " With one addition: "Remember that your initial message still needs to include bug numbers and URL's once the sponsor does become interested." or something like that. > For example, _I_ assumed that since the page on the upload clearly > showed `Closes: #xxxxxx', I didn't need to mention that in the RFS. If > convention is that one _should_ do so, we would save everyone a lot of > time if the template included that. If packages formerly but not > currently in unstable are a special case (and I think they are), then > having some guidelines on how to handle them would be very helpful. Special cases: 1. Packages removed from any existing distribution because such actions are not taken lightly. 2. Packages that have been rejected from NEW previously. 3. Packages that depend on any packages suffering from 1 or 2. 4. Packages already in Debian which have RC bugs that could lead to removal from testing and/or unstable if we were closer to a release. 5. ITA - Intend to Adopt (orphaned package). 6. Transfer of maintenance (or hijacking). Any package that meets any of these criteria needs substantial amounts of extra information in the RFS. It's hard to specify what this information should be, but the basic idea is that "special case" RFS packages (IMHO) must include full details of why the package is in that category. Removals need to include the bug numbers that caused removal and what has been done to prevent those issues recurring. Rejected packages need to include the reasons for rejection from NEW and what has been done to address the reasons for that rejection. If you are adopting an orphaned package, address the reasons why the package was orphaned, include the bug number of the bug that orphaned the package and what you can do to solve those issues. If you are proposing to take over maintenance of a package (or even more drastic, to hijack a package), I would expect to see specific references to attempts to contact the current maintainer and any response, any relevant bug numbers, links to any discussions on debian-devel and full details of the bugs or issues that make such an action necessary in the first place. > I did not see your personal guidelines for sponsorship until well after > our initial encounter, as it is not very prominent on the site. I would like to see that improved. > Since you read so many RFSes, Neil, I do scan most RFS emails on mentors, unless on VAC, yes. I wouldn't say that was unusual. I'm not the only one who has found that RFS emails commonly lack important information. I just complain more loudly than some. ;-) Personally, I think it is better to complain than to ignore RFS emails that don't provide sufficient information. > could you give us a list of, say, > your top-ten pet peeves about things would-be sponsees screw up? 1. Bug numbers are essential. There is no excuse for leaving them out, IMHO. 2. The long description should be included most of the time, epecially for an ITP because nobody in Debian knows what an ITP package is meant to do. Plus, ITP packages commonly include poorly constructed short and long descriptions. An RFS for an ITP can be based on the ITP itself. 3. Always make it absolutely clear if this is a new package or an existing package. Don't just quote the ITP number, say it is an ITP and give the number. 3.1 If not an ITP, it becomes imperative (IMHO) that the RFS includes specific information about the package and the background, including full disclosure of bugs that would be reopened and actions done to prevent the problems reappearing. 4. Check before you send. Maintainers who send multiple RFS emails often make basic mistakes where the repeat emails retain data from the first instead of being updated. Maintainers still send template-based RFS emails with no extra content. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
pgpqGuJF1Ghw_.pgp
Description: PGP signature