Kevin Keane wrote: > Dan Langille wrote: >> Kern Sibbald wrote: >> >> >>> To everyone: >>> In the future, please (everyone) pay careful attention to formating your >>> request (i.e. leading spaces, line separation and such) so that it >>> corresponds exactly to the format in the projects file. As these are >>> presented, they are almost unreadable when copied and pasted into the >>> projects file, and so to make it readable, I have to spend considerable >>> time >>> dealing with formating. If you do not understand what I mean take a look >>> at >>> the current project file and try to find and read some of the more recent >>> submissions. >>> >>> Thanks for your consideration of the request. >>> >> I suggest a slight change of policy. >> >> If a request is accepted, but is in the incorrect format, it should be >> put on hold until the submitter adjusts the format. It is in their >> interest to reformat. >> >> I say "accepted then reformat" because there's no sense in asking >> someone to reformat if it's been rejected. >> >> Of course, I'd also go for "reject the submission if incorrectly >> formated". I think shifting the work to those better suited to carry >> out the work is a good idea. >> >> Developers are not expected to do a bunch of text formating. It's not >> because they can't do it. It's because others can easily do it, thus >> freeing up developer time to do developer things. >> > I'm not sure that the submitters are any better suited to do it, because > it isn't clear at all that the formatting is *that* critical, or exactly > what the format even is. http://www.bacula.org/en/?page=feature-request > describes it, but the way I read it, all it says is which fields you > should put into the feature request. From looking at it, I wouldn't have > known that the Origin and Date field should be intended two spaces (or > is it three?) If it is this critical, maybe you could make that explicit. > > Another issue is that it may be impossible to meet that requirement. > Looking at it, it seems that the misformatting in the line breaks that > prompted Kern to suggest this policy actually was an artifact of the > email MUA or a message transport somewhere along the way. That *will* > happen regularly, in particular when emails are going back and forth > discussing the feature request. > > How about creating a form on the Web site that accepts the various > fields and automatically generates a perfectly-formatted feature request > and emails it to the appropriate mailing list? Put a CAPTCHA on it to > prevent spam, and the problem is mostly solved (misformatting could > still happen while the feature request is being discussed, of course, > but at least the initial request would come out perfectly every time). >
Tradition has it that those that suggest are also volunteering. :) -- Dan Langille BSDCan - The Technical BSD Conference : http://www.bsdcan.org/ PGCon - The PostgreSQL Conference: http://www.pgcon.org/ ------------------------------------------------------------------------------ Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
