On Thu, 13 Sep 2007 21:00:18 -0700 Thanasis Kinias <tkinias@kinias.org> wrote: > I made a post earlier this evening encouraging Neil to let us know what > he views as the major `this pisses me off' errors people make in putting > together RFSes, and it appears that this is one of them. Neil's belief > AFAICT is that a would-be sponsor should not have to look at the package > page on mentors.d.n -- which means that bugs you close must be specified > explicitly in the RFS e-mail (including, then, obviously, the ITP). The RFS should include sufficient information for a sponsor to make a sensible decision about whether to start looking into the package based solely on the content of the RFS itself. That includes all relevant bug numbers, explanations to clarify if this is a new package or an existing package, whether it has been previously sponsored and clarifications like including the long description, providing some information about how this package relates to a package like it that already exists, the benefits of X vs Y and so on. <I need input!> > Neil, is that accurate statement, that your perspective is that a > would-be sponsor should not be expected to look at the package page on > mentors.d.n, and so any relevant information there should be repeated in > the RFS? The sponsor should be able to decide whether to invest time in the package based on the RFS and without having to go to external sources for every single package. When a sponsor is scanning the list, the maintainer should make sufficient information available in the RFS that the sponsor can make a decision about whether to look at that package or move on to the next one. The RFS is all I have to decide whether to review the package and I won't go to external sources until I've made the decision that the package is worth reviewing - I simply don't have time. When that happens, the reply is retitled to ITR: (Intend to Review) before ITS (Intend to Sponsor). The more relevant information that exists in the RFS, the more likely the package is to get to ITR. The less information that exists in the RFS, the more likely the package will raise a series of criticisms and problems, giving more reasons for a sponsor to be concerned that there are hidden gotchas around the corner. IMHO, over 90% of previously unsponsored packages involved in an RFS are not good enough to be included in Debian as-is. Reviewing a package for sponsoring takes a significant amount of time and if I am going to invest that time, I have to be careful about which packages I choose to review. To make those choices, I need information and I only have time to read the RFS so the information must be in the RFS or your request will simply be ignored. > Would it be helpful if we recommended that for package updates the > latest changelog entry be included as well? No, I don't think that would usually be helpful. If there are reasons for including it with a specific package (e.g. an orphaned package where the RFS is linked to an ITA), fine, but it isn't relevant for many packages - especially packages that are new to Debian. > Mark, I'm hoping we can put together a list of things like this to put > on the Web site so that we can have clearer guidelines for prospective > sponsees to know what's expected... There does need to be something that maintainers can read PRIOR to composing the RFS but my sponsorship requirements are linked from mentors.debian.net. (I'll add some more content and update a few sections on that later.) http://people.debian.org/~codehelp/#sponsor http://people.debian.org/~mpalmer/debian-mentors_FAQ.html " 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. " The main mistake made in RFS emails is a lack of information. The bare template is inadequate 99.9% of the time but the template cannot cover all the possible elements required for a useful RFS. Think about the RFS and err on the side of adding more information than less. I am *much* more likely to ignore an RFS that does not include sufficient information in the RFS itself. Sponsors don't have time to follow every link from every RFS email, inspect the mailing list archives for every single ITP or read the upstream webpage JUST to make the decision about whether to look at a particular package vs the next one on the list. Note well the statement in the FAQ: "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." This is the basic problem - too many maintainers are ignoring this section of the FAQ. I just try to ensure that the maintainer at least gets a REASON why I am ignoring their RFS. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
pgpflLPb26KWb.pgp
Description: PGP signature