| On Wed, 2005-09-28 at 14:34 +0200, Christoph Berg wrote: | > Re: David Moreno Garza in <[EMAIL PROTECTED]>
I'll a little busy and it seems that my message to Debian devel to oppose sudden closure of BTS RFPs never got through.... | > > Can you guys please elaborate on this and stop playing within the BTS? | > | Please don't do that. The BTS is not your personal bookmark list. If | > | you want to have that software in Debian, please retitle the Bug to | > | ITP and package it yourself, apparently no one else is interested. | | I also agree on this. I see most of the people reopening automatic | closed bugs like thinking that is "unfair" or anything related, to close | a bug of theirs. "Why would anyone else close a bug of mine even if it | hasn't have activity for 7 years? It's mine, and I decide what to do or | not to do with it". I hope you get my point. I would wish people would be a little more open and understand that that putting more burden on the submitters is not a good thing. First of all the assumption why something isn't packaged in fixed time is not necessarily "nobody is interested". I can think many other possibilities. To me the RFPs are the least problem and I cannot understand why they are under fire. Is that they are easily closed? Is it that the submitter may not be there any more, so nobody much objects? There are much bigger problems where the time should be put. Like for existing packages: - where 7 year old bugs hang in there and nothing is done. - packages, whose maintainers have disappeared (nobody answers to queries, bugs, questions...) - the overall quality of how the bugs are generally handled (autmatization scripts to monitor and WARN that author XXX hasn't fixed bugs in package X, Y, Z, .... in within time YYYYY; months or years). In my case, I'm interested in those bugs and this sudden closure of things where I had spent fair amount of time to track down correct email addresses, correct licenses, correct web pages - found or wrote good explanations is like diminishing the work of the RFP submitter. I may have time in the future to look into those more and perhaps package them, but I certainly have no time to "explain" to the system just for the sake of "requiring to keep the WMPP RFP open". First of all, any such requirements must be put into the policy manual to make it explicit if it is the intention to: - close your submitted WNPP request in fixed time - you're required to dig deep and explain more if you want to keep the request open after XXX days. >From perspetive of this, the requirements put into the shoulders of the submitter: - discourages participation. Why should the submitter care to sent any RFPs, if they will be closed? He may have better time to do, so why try to help some system that does not need that kind of help? - Putting the burden in submitter is wrong approach. He's the postman. He delivers the message. He doesn't necessarily know anything "deep" about the Debian or how it works. To explain why package is needed? Gimme break. Who can master or know 15 000 packages and suggest "why this is better than XXX". Perhaps an elite 24h system admin whose life is Linux, for occasional users - this is not working right. - What are the goals of the RFPs in the first place? Wasn't the idea that prospective packages get their voice and coverage? In the light of recent events it seems more like "hey, we don't need those RFPs, they just fill in the BTS." Perhaps a better management of BTS is then in order. Or those that see managing messages in BTS are difficucult due to volume, that those are educted to evaluate to user better Mail/News reading software that ocntains filters, topic searches, group operations, priority handling feature etc. Shooting down item just to cut down volume doesn't look like correct solution to the annouance some may feel. | Sure, saying "because I want it packaged" being an RFP is quite obvious. | A further explanation on this is what's really needed. This isn't helpful approach in case of RFPs. It may in case of other reopen requests, but certainly not with mass closures. we could think that closer should equally well "explain" it individually the reason for close - otherwise the situation is not balanced. | > David, could you modify your script such that it requests submitters | > to add a justification when reopening the RFP? I'd find that rather | > useful. | | Yes. It was added as a suggestion, but yes, I'm adding it now to request | it strongly. I this will be the procedure, then it must be written into policy manual as well. Until then this would be more like an suggestion. Jari -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
