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). -- Kevin Keane Owner The NetTech Find the Uncommon: Expert Solutions for a Network You Never Have to Think About Office: 866-642-7116 http://www.4nettech.com This e-mail and attachments, if any, may contain confidential and/or proprietary information. Please be advised that the unauthorized use or disclosure of the information is strictly prohibited. The information herein is intended only for use by the intended recipient(s) named above. If you have received this transmission in error, please notify the sender immediately and permanently delete the e-mail and any copies, printouts or attachments thereof. ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/bacula-users
