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
|