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 AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users